From: tr.17687@z991.linuxsc.com   
      
   antispam@fricas.org (Waldek Hebisch) writes:   
      
   > Tim Rentsch  wrote:   
   >   
   >> James Kuyper  writes:   
   >>   
   >>> bart  wrote:   
   >>>   
   >>>> On 28/11/2025 23:23, Keith Thompson wrote:   
   >>>>   
   >>>>> bart  writes:   
   >>>>>   
   >>>>>> On 28/11/2025 02:33, Janis Papanagnou wrote:   
   >>>>>   
   >>>>> [...]   
   >>>>>   
   >>>>>>>>>> You can of course add as many commodity features to "your   
   >>>>>>>   
   >>>>>>> language" as you like.  I seem to recall that one of the design   
   >>>>>>> principles of "C" was to not add too many keywords.  (Not sure   
   >>>>>>> whether 'A.odd' is a function or keyword above [in "your   
   >>>>>>> language"].)   
   >>>>>>   
   >>>>>> It is a reserved word, which means it can't be used as either a   
   >>>>>> top-level user identifier, or a member name.  With extra effort,   
   >>>>>> it could be used for both, but that needs some special syntax,   
   >>>>>> such as Ada-style "A'odd";  I've never got around to it.   
   >>>>>>   
   >>>>>> In Pascal (where I copied it from) it is a reserved word.   
   >>>>>   
   >>>>> In Pascal, "odd" is not a reserved word.  It's the name of a   
   >>>>> predefined function.   
   >>>>   
   >>>> So what's a 'reserved word' then?  To me it is something not   
   >>>> available as a user-identifier because it has a special meaning in   
   >>>> the language,   
   >>>   
   >>> That's a general description, but at least in C, there's several   
   >>> different kinds of reserved identifiers, each kind specifies   
   >>> different restrictions on user code use of that identifier.   
   >>>   
   >>> 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.   
   >   
   > Hmm, looking at '/usr/include/string.h' on my machine I see definitions   
   > of things like   
   >   
   > __GLIBC_INTERNAL_STARTING_HEADER_IMPLEMENTATION   
   > __need_size_t   
   >   
   > and lot of similar things.  I do not recall seeing any user   
   > documentation listing them.  Does this mean that gcc+glibc   
   > is noncompilant in this aspect?   
      
   I think it's reasonable to say that the appearance of a macro   
   name being #define'd in a standard header qualifies as   
   documenting the name being #define'd.  As long as the #define is   
   readable in an ordinary source file, there isn't any mystery   
   about the name being used or what its definition is.  I suppose   
   that to satisfy the letter of the C standard, the accompanying   
   document would need to incorporate the system header files by   
   reference, but surely the header files satisfy the spirit of   
   providing the required documentation.  Implementation-defined   
   values for things like CHAR_BIT and INT_MAX fall under the same   
   rule for documentation as do extensions, yet as far as I know   
   these values are defined only in system header files, and not in   
   any separate document.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)