On Apr 4, 2005, at 11:49 PM, Kyle Moffett wrote:
On Apr 04, 2005, at 17:25, Richard B. Johnson wrote:I don't find stdint.h in the kernel source (up to 2.6.11). Is this going to be a new addition?
Uhh, no. stdint.h is part of glibc, not the kernel.
It would be very helpful to start using the uint(8,16,32,64)_t types because they are self-evident, a lot more than size_t or, my favorite wchar_t.
You miss the point of size_t and ssize_t/ptrdiff_t. They are types guaranteed to be at least as big as the pointer size.
IIRC, It is guaranteed that size_t can correctly represent the largest object which
can be malloced. This usually coincides with the width of a pointer, but not
neccesarily.
uint8/16/32/64, on the other hand, are specific bit-sizes, which may not be as fast or correct as a simple size_t.
Using specific widths may yield benefits on one platform, whilst proving a real
bottleneck when porting something to another. A potential of problems easily
avoided by using plain-vanilla integers.
Linus has pointed out that while it doesn't matter which of __u32, u32, uint32_t, etc you use for kernel private interfaces, you *cannot* use anything other than __u32 in the parts of headers that userspace will see, because __u32 is defined only by the kernel and so there is no risk for conflicts, as opposed to uint32_t, which is also defined by libc, resulting in collisions in naming.
Strictly speaking, a definition starting with a double underscore is reserved for use
by the compiler and associated libs, this such a declaration would invade implementation
namespace. The compilers implementation, that is.
In this case, the boundary is a bit vague, i see that, since a lot of header definitions also reside
in the /usr/include hierarchy.
I think it would be usefull to at least *agree* on a standard type for 8/16/32/64-bit integer types. What
I see now as a result of grepping for 'uint32' is a lot more confusing than stdint.h
There is u32, __u32, uint32, uint32_t, __uint32_t...
Especially the types with leading underscores look cool, but in reality may cause a conflict with compiler
internals and should only be used when defining compiler libraries. The '__' have explicitly been put in by
ISO in order to avoid conflicts between user-code and the standard libraries, so if non-compiler-library code also starts using '__', just coz it looks cool, that cunning plan is undone.
Furthermore, I think it's wise to convince the community that if not needed, integers should not be specified
by any specific width.
Regards,
Renate Meijer.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
