Messages in this thread | | | Date | Tue, 14 Dec 2004 07:49:05 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [RFC] Splitting kernel headers and deprecating __KERNEL__ |
| |
On Tue, 14 Dec 2004, Werner Almesberger wrote: > > Hmm, so you're predicting problems if user space includes something > that uses uint32_t ? Wouldn't either of these work (descriptive file > names for clarity): > > 1) include/linux-user/foo.h: > #include <stdint.h> > #include <linux-kernel-and-user-common/foo.h>
No. Because when you include <sys/ioctl.h> (which includes the <linux-user/foo.h>, the POSIX/SuS/whatever namespace rules say that YOU MUST NOT pollute the namespace with the names from stdint.h.
The user is supposed to see "int32_t" and friends _only_ if the user himself includes <stdint.h> or one of the very specific headers that is documented by the standard to include it.
Trust me. We are NOT going to use <stdint.h> in the kernel.
This is a common issue with namespace pollution. For example, this program is perfectly valid afaik (well, except for being _stupid_, but that's another issue):
#include <stdio.h>
const char *int32_t(int i) { return i ? "non-zero" : "zero"; }
int main(int argc, char **argv) { return printf("argc is %s\n", int32_t(argc)); }
Get the picture? The user may _use_ names that are defined for the standard - like "strlen()" or "uint32_t" - for his own nefarious purposes, because they are _only_ defined if you include the right header files.
And trust me, the rules are really arcane. Not only do you have several standards, and several versions, you have various local rules too, ie gcc and glibc make up their own rules about things that depend on compiler flags etc.
And that is why a kernel header file must not define them, and by implication, cannot use these names.
Because the whole _point_ of having kernel header files that can be used in user-space is that they are helpers for things like <sys/ioctl.h> etc, that would just copy them.
If we are going to pollute the user-visible namespace in random ways, the whole discussion is pointless. At that point, glibc (or any other libc) can't use those API headers anyway.
Remember: the _biggest_ reason to make kernel headers available is not to user programs that want them, but to libc and friends.
Linus - 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/
| |