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 _______________________________________________ vbox-dev mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-dev
