From: antispam@fricas.org   
      
   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?   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)