Linux Kernel Mailing List Archive

From: Werner Almesberger (wa@almesberger.net)
Date: Tue Dec 14 2004 - 16:46:05 EST

• Next message: Roland McGrath: "Re: [PATCH 1/7] cpu-timers: high-resolution CPU clocks for POSIX clock_* syscalls"
• Previous message: Jon Smirl: "Re: [PATCH] fix ROM enable/disable in r128 and radeon fb drivers"
• In reply to: Linus Torvalds: "Re: [RFC] Splitting kernel headers and deprecating __KERNEL__"
• Next in thread: Linus Torvalds: "Re: [RFC] Splitting kernel headers and deprecating __KERNEL__"

Linus Torvalds wrote:
> iow, using "uint32_t" and friends is _stupid_. The only fathomable
> argument for doing so would be consistency,

I think consistency is a worthwhile goal in this case. I guess we
can work towards consistency even without using uint32_t in kernel
headers.

This still bears the risk that people will copy __u32 and friends
from headers to then non-portable applications, but I guess that's
something we just have live with.

Since C now finally has standard types with well-defined sizes, I
think there's little reason for applications not to use these types.
So peer pressure should eventually make everyone at least compatible.

A first step towards enabling converence would be to _guarantee_
that glibc types are _identical_ to the kernel types, e.g.

/usr/include/stdint.h:
#include <linux-user/types.h> /* only __u32 and such */

typedef __u32 uint32_t;
...

(If they just "happen to be the same", people may still not trust
this, and will feel justified inventing their own schemes. And as
ugly as uint32_t may look, it's still infinitely better than code
where each library contributes its own set of sized integers ...)

Then, in a few years, when uint32_t and friends are considered
as much a part of the C language as "int", we might be able to
sed s/__u32/uint32_t/g the kernel, and obtain perfect consistency.

Does this sound reasonable ?

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

Now, what do we do with them when they are inside the kernel,
far from any interfaces ? Live and let live ? Deprecate them
early on January 1st, when nobody is watching ? :-)

Thanks,
- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
-
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/

• Next message: Roland McGrath: "Re: [PATCH 1/7] cpu-timers: high-resolution CPU clocks for POSIX clock_* syscalls"
• Previous message: Jon Smirl: "Re: [PATCH] fix ROM enable/disable in r128 and radeon fb drivers"
• In reply to: Linus Torvalds: "Re: [RFC] Splitting kernel headers and deprecating __KERNEL__"
• Next in thread: Linus Torvalds: "Re: [RFC] Splitting kernel headers and deprecating __KERNEL__"