Messages in this thread | | | Date | Sun, 2 Apr 2006 12:32:23 +0200 | From | Pavel Machek <> | Subject | Re: [RFC][PATCH 1/2] Create initial kernel ABI header infrastructure |
| |
Hi!
> >>__KABI_ everywhere will just make your headers totally > >>unreadable. Please don't do that. > > > >Ack, I agree. > > Let me reiterate two facts: > > (1) The various C standards state that the implementation should > restrict itself to symbols prefixed with "__", everything else is > reserved for user code (Including symbols prefixed with a single > underscore). > (2) GCC predefines a large collection of symbols, macros, and > functions for its own use, and this set is not constant (just look at > the number of new __-prefixed symbols added between GCC 3 and 4. In > addition, we're not just compiling this code under GCC, but people > will also be using it (hopefully unmodified) under tiny-cc, intel-cc, > PGI, PathScale, Lahey, ARM Ltd, lcc, and possibly others. It > probably does not need to be stated that for something as userspace- > sensitive as the KABI headers we should not risk colliding with > predefined builtins in any of those compilers. > > So my question to the list is this: > Can you come up with any way other than using a "__kabi_" prefix to > reasonably avoid namespace collisions with that large list of > compilers? If you have some way, I'd be interested to hear it, but > as a number of those compilers are commercial I'd have no way to test > on them (and I suspect most people on this list would not either).
No, you should just not care about anything but gcc. intel-cc-version-0.3.2.1.2.5 could use __kabi_struct_dirent or whatever, and collide anyway. By adding __kabi you just make it less likely.
I believe __ is enough. If there's one conflict with some obscure compiler, we can simply fix the conflict (or even fix the compiler :-).
If you feel __ is too dangerous, you may go __k ... It will not look as ugly as __kabi_ , and should be very safe. Pavel
-- Picture of sleeping (Linux) penguin wanted... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |