Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[Linus Torvalds <torvalds@osdl.org>]

On Tue, 14 Dec 2004, Werner Almesberger wrote:
> 
> Would you agree that the use of stdint.h types is acceptable for
> new interfaces, provided that these come with the warning that
> their use may pull in all of stdint.h ?

Not really. 

Two reasons:
 - The fact is, things are interdependent. And this thing is all about 
   _avoiding_ implicit dependencies, and rules like "if you include _this_ 
   particular header file, then you must include yyy.h first, or you can't 
   do zzzz".
 - uint32_t and friends aren't all that nice anyway. Quite frankly, there 
   is nada, zilch, _zero_, reason to use them over the __u8/__u16/__u32.
   In contrast, the __u8/__u16/__u32 types have obvious advantages, 
   ranging from the _lack_ of namespace collission issue to just plain 
   consistency.

iow, using "uint32_t" and friends is _stupid_. The only fathomable 
argument for doing so would be consistency, but since BY DEFINITION we 
cannot be consistent if we use them (since we cannot and must not use them 
anywhere), that _single_ reason for using them is actually the biggest 
reason to NOT use them.

See my point?

> If this is as unpredictable as you describe it, it would mean
> that also new interfaces which need to specify an exact integer
> size would require new sets of type names.

No. They require an OLD set of type names, that have existed for years in
the kernel, and that are already used widely.

In other words, they require __u8/__u16/__u32/__u64. That _is_ the way to 
specify a sized type in kernel headers. It has been that way for years, 
it's extremely readable, it's consistent, and it's compact.

In other words, u8/u16/u32/u64 (and the signed versions: s8 and friends)  
_are_ the standard names in the kernel, and the __ versions have always 
existed alongside them for things like header files that have namespace 
issues.

So forget about that stupid abortion called "uint32_t" already. It buys
you absolutely nothing.

			Linus