Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

Linus Torvalds
2004-12-14T18:09:22Z

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