[PATCH v1 00/35] Require GNU C --at least GCC 5 or Clang 4-- in headers

[Zack Weinberg]

On Mon, Nov 10, 2025, at 5:35 AM, Alejandro Colomar wrote:
> On Mon, Nov 10, 2025 at 11:17:48AM +0100, Florian Weimer wrote:
>> >> > Alejandro Colomar (35):
>> >> >   Assume __GNUC__
>> >> >   Assume __GNUC__ >= 2
>> >> >   Assume __GNUC__ >= 3
>> >> >   Assume __GNUC__ >= 4
>> >> 
>> >> No, this breaks some versions of Oracle Pro*C, tools based on CKit (such
>> >> as mlnlffigen), and many other things.
>> >
>> > Thanks!  Is it because of 'Assume __GNUC__'?  Or because one of the
>> > version bumps?  Could we assume a higher __GNUC__ but keep allowing
>> > non-__GNUC__?
>> 
>> I don't know.  Changing <sys/cdefs.h> is probably not advised because
>> it's shared with gnulib.  Support for GCC 1 can probably be removed from
>> the other headers, but the cleanup opportunities seem rather minimal.
>
> Apart from the cleanup opportunity, there's the benefit on new code.
> The origin of this was the discussion about adding a new function that
> returns a _Bool.  If we require a C99 compiler, new code could be much
> better.

In public headers we need to be really cautious.  Yeah, most C compilers
written in the past decade or so _probably_ support _most_ of C1999, but
do they support _all_ of its language features?  I don't even know where
to begin researching that question.

At present, our requirement is "a C19_8_9-compliant compiler that also
implements a short but poorly documented list of originally GCC-specific
features."  (The only such features I actually know about are __gnuc_va_list
and a couple of places where our headers try to use _part of_ the compiler's
headers.)  It will probably go more smoothly if we raise this bar incrementally.
Saying that we now require the compiler to implement _Bool is _probably_ fine
(but still needs to be researched).  Saying that we require all of C1999, all
at once, is, well, it's ultimately not my decision but it is too drastic a
change for my taste.  Similarly, enlarging the set of required GCC-compatible
language extensions one by one (e.g. requiring support for asm("symbol") on
function declarations) is probably going to go more smoothly than raising the
bar all at once.

Concrete advice for you, Alejandro: Find out exactly what subset of C1999,
C2011, etc. are implemented by current versions of TCC and by the C compiler
in GNU Mes.  Also find out what subset of GCC's extensions are implemented
by those compilers.

zw