Maybe I can start another religious war to replace the GGI "discussion" ;-)
I'm trying to do something really simple: I'm trying to write a header file
that can be included both from the kernel and from a user space program.
The latter will be compiled in an environment using libc.5 or glibc2.
Now, in that header file, I want to express an integer quantity of a given
size, e.g. an unsigned integer of 32 bits.
In the kernel, I can use:
__u32
u32
In glibc2, I can use:
u_int32_t
In libc.5, I can use:
__u32
u_int32_t
The intersection of the three sets is empty, so my header file will have
to do something "special".
Is u_int32_t "official" in any way ? POSIX 1003.1, 1996 doesn't list it
or anything similar. Of course it's okay for libc to introduce such an
identifier (POSIX 1003.1 2.7.2).
Likewise, what's the situation with __u32 ? Its use is of course allowed
by ANSI C 7.1.3. For backwards compatibility, this seems to be what
glibc2 should have provided.
It seems that I either have to introduce u_int32_t in the kernel name
space, __u32 in the glibc2 name space, or generate yet another set of
identifiers. Are linux/types.h and glibc2 sys/types.h moving towards a
solution of this problem or will I have to live forever with some
#ifdef __KERNEL__ do this #else do that #endif
hack ?
- Werner
-- _________________________________________________________________________ / Werner Almesberger, DI-ICA,EPFL,CH werner.almesberger@lrc.di.epfl.ch / /_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu