All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.