[vbox-dev] reserved identifier violation
Jens Schweikhardt
Jens.Schweikhardt at Sun.COM
Tue Feb 17 11:05:12 GMT 2009
Markus Elfring wrote:
> Thanks for your detailed explanation.
>
>
> Jens Schweikhardt wrote:
>> Any library (or API) provider faces a dilemma because he must invade one
>> of the two namespaces. VirtualBox chose to not invade the application
>> name space where practical. This means use of underscores as prefix in
>> places where the application writer is not supposed to use such identifiers.
>
> I find this a questionable design decision.
Why? There are good arguments either way.
>> While this is technically causing undefined behavior, it is
>> a conscious decision because we support compilation of VirtualBox only
>> on a very limited number of implementations, the implementation
>> namespace of which is known to us.
>
> Would you like to avoid more situations to build on undefined behavior?
We're avoiding it where we have to. Note that VirtualBox is not an ISO C
program to begin with. As such it must invoke undefined behavior in many
ways, starting with #include <sys/ioctl.h> and not ending with rewriting
the set of portable runtime functions.
>> The __BEGIN_DECLS macro is a good example for this.
>
> I imagine that this symbol might be too short to avoid all potential conflicts.
Even if we prefixed it with VBOX_, who says it wouldn't clash one day
with Visual Basic's Open X11 Interface? (Just to invent a name...)
>> As for header include guards, using __FOO_H is a common way to not
>> invade the app name space (see libvirt or the python binding for XPCOM
>> and many more).
>
> I have got the impression that this is just a bad habit if the reserved naming pattern is used in source code which does not belong to the implementation of a (C/C++) compiler.
> http://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html
If you read that page, count the number of rules, which identifier is
reserved and when. How much easier is it to use __foo and be done?
Especially if you have a good understanding of the implementation
namespace anyway? It appears you are arguing for not entering the
implementation name space for standard conformance's sake. This might be
a goal for a program like grep, but it's not for a program like
VirtualBox, which by design has no way to be standards conforming in
every respect because it occupies a middle ground between application
and implementation.
> I suggest to use longer names to make important identfiers unique.
> http://en.wikipedia.org/wiki/Include_guard#Difficulties
That's just trading one namespace pollution for another. Remember the
dilemma I talked about previously.
>> If you happen to find a real problem due to identifier name clash (in an
>> implementation we support) we'd be of course happy to hear about it.
>
> I try to increase attention for such an implementation detail before software developers and users are affected in unexpected ways by wrong applications of naming conventions.
Rest assured we do have a naming convention; it is oriented towards
practicality, and avoids invading the application name space
unnecessarily. Strict ISO C conformance could never be a goal here.
I'm well aware of the issue you're bringing attention to and in my own
ISO C apps I carefully chose identifiers from the app name space.
Believe it or not, I even wrote a program to check for name space issues
in C implementations so that compiler vendors can improve their
sometimes shoddy understanding of it (
http://www.de.ioccc.org/years-spoiler.html#1998 and look for schweikh1)
But you /are/ barking up the wrong tree here :-)
Regards,
Jens Schweikhardt
More information about the vbox-dev
mailing list