Re: [RFC] Splitting out kernel<=>userspace ABI headers

[Denis Vlasenko]

On Saturday 03 September 2005 08:55, Kyle Moffett wrote:
> On Sep 3, 2005, at 00:28:59, Erik Andersen wrote:
> >> Absolutely not.  This would be a POSIX namespace violation; they
> >> *must* use double-underscore types.
> >
> > I assume you are worried about the stuff under asm that ends up
> > being included by nearly every header file in the world.  Of
> > course asm must use double-underscore types.  But the thing is,
> > the vast majority of the kernel headers live under
> > linux/include/linux/ and do not use double-underscore types, they
> > use kernel specific, non-underscored types such as s8, u32, etc.
> > My copy of IEEE 1003.1 and my copy of ISO/IEC 9899:1999 both fail
> > to prohibit using the shiny new ISO C99 type for the various
> > #include <linux/*> header files, which is what I was suggesting.
> 
> Anything in linux/* that is included by userspace should not
> presume that stdint.h has already been included or include it on
> its own, because the userspace program may have already made its
> own definitions of uint32_t, or it may not want them defined at
> all.

Is this an excercise in academia? Userspace app which defines
uint32_t to anything different than 'typedef <appropriate int type>'
deserves the punishment, and one which does have such typedef
instead of #include stdint.h will not notice.

All these u32, uint32_t, __u32 end up typedef'ing to same
integer type anyway...

Why should we care of such 'struct uint32_t { ... };' pervert cases?
If we will do, I suspect we will end up with __________u32's.
We already have a lot of __'s:

linux/cache.h:#define ____cacheline_aligned __attribute__((__aligned__(SMP_CACHE_BYTES)))
linux/rcupdate.h:                             typeof(p) _________p1 = p; \

*three underscores* line count over kernel's include/:

# grep -r ___ . | wc -l
10129

and "only" two underscores:

# grep -r __ . | wc -l
72216
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/