From: tr.17687@z991.linuxsc.com   
      
   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.   
      
   Note by the way that the description in N3220 section 6.10.10.1   
   paragraph 2 makes using #define or #undef be undefined behavior only   
   for macro names in the subclause (and also a short list of other   
   identifiers).  Hence any other predefined macro name may be used,   
   definedly, simply by using #undef and then #define for the macro   
   name in question (in particular, under C23 rules, but not earlier   
   versions of the C standard).   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)