git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: git@vger.kernel.org
Cc: Stan Hu <stanhu@gmail.com>
Subject: Re: [PATCH RESEND] sane-ctype: fix compiler error on Amazon Linux 2
Date: Thu, 10 Jul 2025 11:14:36 +0200	[thread overview]
Message-ID: <aG-EfIfyXxmS_x22@pks.im> (raw)
In-Reply-To: <20250710-pks-ctype-v1-1-1db7e7568ea2@pks.im>

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.

Patrick

[1]: <20250710-pks-ctype-v1-1-c668b308d628@pks.im>

  reply	other threads:[~2025-07-10  9:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-10  9:12 [PATCH RESEND] sane-ctype: fix compiler error on Amazon Linux 2 Patrick Steinhardt
2025-07-10  9:14 ` Patrick Steinhardt [this message]
2025-07-10  9:26   ` Patrick Steinhardt
2025-07-10 10:17     ` Toon Claes
2025-07-10 21:01     ` Junio C Hamano
2025-07-11  7:56       ` Patrick Steinhardt
2025-07-11 15:11         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aG-EfIfyXxmS_x22@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=stanhu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).