From: tr.17687@z991.linuxsc.com   
      
   Keith Thompson  writes:   
      
   > James Kuyper  writes:   
   >   
   >> On 2025-08-05 17:13, Kaz Kylheku wrote:   
   >>   
   >>> On 2025-08-04, Michael S  wrote:   
   >>>   
   >>>> On Mon, 4 Aug 2025 15:25:54 -0400   
   >>>> James Kuyper  wrote:   
   >>   
   >> ...   
   >>   
   >>>>> If _BitInt is accepted by older versions of gcc, that means it   
   >>>>> was supported as a fully-conforming extension to C. Allowing   
   >>>>> implementations to support extensions in a fully-conforming   
   >>>>> manner is one of the main purposes for which the standard   
   >>>>> reserves identifiers.  If you thought that gcc was too   
   >>>>> conservative to support extensions, you must be thinking of the   
   >>>>> wrong organization.   
   >>>>   
   >>>> I know that gcc supports extensions.   
   >>>> I also know that gcc didn't support *this particular extension*   
   >>>> up until quite recently.   
   >>>   
   >>> I think what James means is that GCC supports, as an extension,   
   >>> the use of any _[A-Z].* identifier whatsoever that it has not   
   >>> claimed for its purposes.   
   >>   
   >> No, I meant very specifically that if, as reported, _BitInt was   
   >> supported even in earlier versions, then it was supported as an   
   >> extension.   
   >   
   > gcc 13.4.0 does not recognize _BitInt at all.   
   >   
   > gcc 14.2.0 handles _BitInt as a language feature in C23 mode,   
   > and as an "extension" in pre-C23 modes.   
   >   
   > It warns about _BitInt with "-std=c17 -pedantic", but not with   
   > just "-std=c17".  I think I would have preferred a warning with   
   > "-std=c17", but it doesn't bother me.  There's no mention of _BitInt   
   > as an extension or feature in the documentation.  An implementation   
   > is required to document the implementation-defined value of   
   > BITINT_MAXWIDTH, so that's a conformance issue.  In pre-C23 mode,   
   > since it's not documented, support for _BitInt is not formally an   
   > "extension";  it's an allowed behavior in the presence of code that   
   > has undefined behavior due to its use of a reserved identifier.   
   > (This is a picky language-lawyerly interpretation.)   
      
   To clarify the last part, undefined behavior is allowed only   
   because a diagnostic was generated.  If there were no diagnostic   
   then it would have to be documented as an extension, otherwise   
   the implementation would not be conforming.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)