Re: standards/46223: reserved identifier violation

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR standards/46223; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: standards/46223: reserved identifier violation
Date: Sat, 14 Apr 2012 02:31:21 +0700

     Date:        Fri, 13 Apr 2012 16:35:03 +0000 (UTC)
     From:        Markus Elfring <Markus.Elfring%web.de@localhost>
     Message-ID:  <20120413163503.5306963B9FE%www.NetBSD.org@localhost>
 
   |  I dare to point out open issues in the standard-compliant application
   |  of C/C++ naming conventions.
 
 Someone please close this PR - there cannot be a violation of this
 particular standards requirement in NetBSD - by definition.
 
 These "us vs them" rules that the standards guys like to impose
 upon the world are almost always disasters.   The problem is that
 there isn't just "us" & "them", or perhaps more accurately, there
 are a whole huge class of objects that can be either us or them,
 whichever one of those is not me.
 
 From a language standardiser's viewpoint, a rule like this seems to
 make sense, and "us" are the language standardisation committee, and
 "them" is everyone else (sometimes they're kind of gracious and admit
 implementors of the language as a part of the us group, but not always).
 
 This makes things simple, for this particular issue, it means that the
 language can always define new reserved magic words, and know that no
 user will ever be inconvenienced by that - or not unless the user has
 violated the rules.
 
 At the other extreme, the canonical example of "them" is the author of
 a "hello world" application - clearly such a person is not supposed to
 use _X identifiers, and if they do they are liable for whatever problems
 that causes them.  Of course, in 99% of cases, no-one is going to
 care what the author of such a program chooses to name their identifiers,
 as it never bothers anyone else in any way at all.  As long as it
 works, it is OK, whether it breaks  the rules or not.  The author is
 taking a (small) risk that if they move their application to another
 platform it may not build (or just perhaps, operate) correctly - that's
 a portability bug in the application, but as an application author,
 while that one is worth some consideration, there are far more insidious
 and harder to detect and deal with potential portability problems that
 I'd worry about much more than my choice of identifier names.
 
 In between we have everything else - the language compiler implementation
 (and any extensions it makes to the standard language), the language
 runtime environment, the basic library functions that make the language
 useful in practice, the operating system interface, add on sub-systems,
 and extra third party sub-systems and libraries.
 
 From the language standardiser's viewpoint, none of those, with the possible
 exception of the language implementation, and maybe its runtime, are part
 of "us", and none of the rest of it should be touching the reserved
 identifier space.
 
 From the point of view of the author of application programs, all of that
 stuff is part of the implementation (that is, everything that's on the
 system already when the application is about to be compiled) - the
 important point being that the application author is supposed to be able
 to use any identifiers he chooses, other than the reserved ones (which
 include the _X identifiers, and the various reserved words documented as
 part of the language, or as part of the documented interface of some other
 sub-system the application uses.)   But all those intermediate pieces also
 need to define hidden identifiers (like the names for the character classes
 in the libc ctype macros, ...) that are not part of the documented
 interface, yet still must not conflict with the application's identifier space.
 
 The only place all those system pieces (sys/*.h header files, libc
 header files, X11 header files, libcurses (etc) header files, linpng
 header files (etc)) can find to define identifiers that cannot bother
 a conforming application is the _X namespace.
 
 That's OK, as from the application viewpoint, which is the only one that
 really matters, all of that stuff is a part of the implementation.
 
 What that means is that it is entitled to use _X identifiers - and the "it"
 here is everything that's distributed with NetBSD (including pkgsrc), and
 thus it is never proper to complain about a violation of this particular
 rule anywhere in NetBSD.   So this PR should be closed and ignored.
 
 I suppose it could be argued that parts of NetBSD that can't be used by
 other applications (like the source code for cat, or ls or whatever)
 could be excluded from that, and if any of those things define _X type
 identifiers, that could be considered a bug.   But why would anyone care?
 As long as it works, it works, while making those programs portable to
 other systems would be nice, it isn't really a requirement, and within
 NetBSD, any such identifier (I doubt any exist, but they might I suppose)
 is clearly not causing a problem.   If it ever does due to changes elsewhere,
 it would get fixed pretty quickly.
 
 Of course, it is incumbent upon the implementation (that being NetBSD here)
 to make sure its use (throughout all parts of the implementation) of any
 of the identifiers from the implementation reserved space is all consistent,
 and safe - and if any of the sub-=parts of the implementation add new
 identifiers from this space, other parts may need to be updated to restore
 consistency, but that's OK, that's just a part of the system maintenance.
 
 kre