Messages in this thread | | | Date | Tue, 14 Dec 2004 18:46:05 -0300 | From | Werner Almesberger <> | Subject | 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/
| |