[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: standards/46223: reserved identifier violation
The following reply was made to PR standards/46223; it has been noted by GNATS.
From: Robert Elz <kre%munnari.OZ.AU@localhost>
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>
| 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
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.
Main Index |
Thread Index |