[PATCH v3 2/7] malloc/obstack.h: Assume GCC supports __extension__

[Joseph Myers]

On Mon, 10 Nov 2025, Paul Eggert wrote:

> Also, there should be a section in the manual that says what user compilers
> are supported. For GCC we can simply say something like "2.8 or later"; for
> other compilers we needn't list specific compilers or versions, merely what C
> features are assumed. I suggest doing this by uncommenting the last paragraph
> in maint.texi (and thus bringing back an old compatibility appendix) and
> bringing it up to date. For the patches in this series, the following features
> should be documented in that part of the manual:
> 
> * #warning
> * statement expressions (assuming we insist on them)
> * long long and associated macros like LLONG_MAX
> * a stdarg.h that defines va_list
> 
> Doing this documentation would perhaps be the most painful and important part
> of the whole exercise.

Note there are separate considerations here:

* For users: certain language features (on top of C90 / C++98) are 
required to use the headers, or certain features in the headers.  In some 
cases, the language feature is only needed for a very specific, limited 
part of the headers (for example, <complex.h> requires __builtin_complex 
for the CMPLX macros, but everything else in the installed headers should 
work without that feature).

This does *not* need to mention features only relevant for optimizations 
or extra diagnostics, because the relevant parts of the headers can be 
conditional without affecting the API provided to users.  It's only 
language / compiler features that are needed to provide a particular 
public API that are relevant here.  On that basis, I don't see any need to 
require #warning, and I doubt there's a need for statement expressions 
(but maybe a detailed analysis could show some feature to be hard to 
provided in the headers without them).

The interactions between compiler and library headers (e.g. 
__need___va_list) are a tricky sub-part of this.  I think the aim in such 
cases is that the fallback, if the header doesn't support the __need_* 
protocol from the GCC headers, is that the glibc headers will still work 
but might expose more declarations from the compiler headers than that 
particular header is meant to (e.g. __need___va_list is meant to avoid 
exposing names such as va_list, just declaring __gnuc_va_list instead).

* For glibc development: there is a *rationale* for each feature for why 
some things are problematic to support without that feature, typically for 
ABI reasons.  Documenting that makes sense as well, but for glibc 
developers rather than for end users as the target audience.

-- 
Joseph S. Myers
josmyers@redhat.com