From: tr.17687@z991.linuxsc.com   
      
   James Kuyper  writes:   
      
   > Tim Rentsch  wrote:   
   >   
   >> James Kuyper  writes:   
   >   
   > ...   
   >   
   >>> Note: in C2023, the [predefined macro names] section says:  "Any other   
   >>> predefined macro names:  shall begin with a leading underscore   
   >>> followed by an uppercase letter;  or, a second underscore...".  For   
   >>> earlier versions of the standard, user code should avoid using such   
   >>> identifiers because they were reserved for all purposes, but that's no   
   >>> longer the case.  Now, they should be avoided because they may be   
   >>> pre-defined by the implementation, which means that any attempt to use   
   >>> them might have unpredictable results.   
   >>   
   >> That's right in the sense that if the implementation is unknown then   
   >> unexpected results may occur.  However, if the implementation is   
   >> known, then we can find out what results are expected by consulting   
   >> the implementation's documentation for extensions, since any such   
   >> macro name must qualify as an extension, and so much be documented.   
   >   
   > J.5 identifies as extensions only "... predefined macros with names that   
   > do not begin with an underscore." (J.5, J.5.13)   
      
   That doesn't invalidate what I said.  And anyway Annex J is only   
   informative, not normative.   
      
   > They are not identified as implementation-defined, so there is no   
   > obligation to document them.   
      
   Let me clarify my earlier comment.  An implementation is free to   
   accept almost anything at all, as long as a diagnostic is issued.   
   But any usage[*] that would otherwise be a syntax error or violate   
   a constraint, if accepted without issuing a diagnostic, must be an   
   extension and so must be documented.   
      
   [*] an ordinary use, not a declaring or defining use.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)