Re: [PATCH RESEND] sane-ctype: fix compiler error on Amazon Linux 2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 10, 2025 at 11:14:36AM +0200, Patrick Steinhardt wrote:
> On Thu, Jul 10, 2025 at 11:12:40AM +0200, Patrick Steinhardt wrote:
> > Compiling Git fails on Amazon Linux 2 when using GCC 7.3.1 with the
> > following compiler error:
> > 
> >     In file included from compat/posix.h:449:0,
> >                      from git-compat-util.h:26,
> >                      from daemon.c:3:
> >     compat/../sane-ctype.h:29:60: error: expected expression before ']' token
> >      #define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
> >                                                                 ^
> >     compat/../sane-ctype.h:29:72: error: expected ')' before '!=' token
> >      #define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
> >                                                                             ^
> >     compat/../sane-ctype.h:29:60: error: expected expression before ']' token
> >      #define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
> >                                                                 ^
> >     ... lots of similar lines ...
> > 
> >     compat/../sane-ctype.h:45:50: error: expected declaration specifiers or '...' before numeric constant
> >      #define toupper(x) sane_case((unsigned char)(x), 0)
> >                                                       ^
> >     /usr/include/ctype.h:142:12: error: expected identifier or '(' before 'int'
> >      extern int isascii (int __c) __THROW;
> >                 ^
> >     compat/../sane-ctype.h:30:26: error: expected ')' before '&' token
> >      #define isascii(x) (((x) & ~0x7f) == 0)
> >                               ^
> >     compat/../sane-ctype.h:30:35: error: expected ')' before '==' token
> >      #define isascii(x) (((x) & ~0x7f) == 0)
> >                                        ^
> >     In file included from /usr/include/features.h:423:0,
> >                      from /usr/include/unistd.h:25,
> >                      from compat/posix.h:90,
> >                      from git-compat-util.h:26,
> >                      from daemon.c:3:
> >     compat/../sane-ctype.h:44:30: error: expected declaration specifiers or '...' before '(' token
> >      #define tolower(x) sane_case((unsigned char)(x), 0x20)
> >                                   ^
> >     compat/../sane-ctype.h:44:50: error: expected declaration specifiers or '...' before numeric constant
> >      #define tolower(x) sane_case((unsigned char)(x), 0x20)
> >                                                       ^
> >     compat/../sane-ctype.h:45:30: error: expected declaration specifiers or '...' before '(' token
> >      #define toupper(x) sane_case((unsigned char)(x), 0)
> >                                   ^
> >     compat/../sane-ctype.h:45:50: error: expected declaration specifiers or '...' before numeric constant
> >      #define toupper(x) sane_case((unsigned char)(x), 0)
> >                                                       ^
> > 
> > This error bisect back to 75a044f748 (git-compat-util.h: split out
> > POSIX-emulating bits, 2025-02-18), where lots of bits got split out of
> > "git-compat-util.h" into a new "compat/posix.h" header.
> > 
> > The compiler error isn't immediately obvious, doubly so because the
> > actual errors are ~3x as long as the above snippet. But what happens
> > here is that we transitively include <ctype.h> after we have included
> > our own "sane-ctype.h" header. Consequently, the function declarations
> > that exist in <ctype.h> for isascii(3p) et al will be mangled by our
> > macros of the same type. The result is of course completely broken.
> > 
> > It's unclear why this issue only happens on Amazon Linux 2. My guess is
> > that it's either specific to the compiler version or specific to the
> > glibc version. We don't explicitly include <ctypes.h> anywhere, but it's
> > being transitively included. So chances are that later versions of the
> > toolchain reorganized their headers so
> 
> Hrmpf, what's going on here? Both this email and the first one at [1]
> are getting truncated... I'll debug.

I've tested with multiple other recipients, works alright there. No
truncation, the mail comes through as expected. I'm a bit clueless right
now. Konstantin, do you have any idea why this might have happened?

Meanwhile, I'll include the patch as an attachment.

Patrick





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux