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.
The point of specific-width integers is to preserve a specific binary format, such as a filesystem on-disk data structure, or a kernel-userspace ABI, etc. If you just need a number, use a different type.
Strictly speaking, a definition starting with a double underscore is reserved for use by the compiler and associated libs
Well, _strictly_speaking_, it's "implementation defined", where the "implementation" includes the kernel (due to the syscall interface).
this such a declaration would invade implementation namespace. The compilers implementation, that is.
But the C library is implicitly dependent on the kernel headers for a wide variety of datatypes.
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.
Some of which are produced by kernel sources: /usr/include/linux, /usr/include/asm, etc.
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
Well, Linus has supported that there is no standard, except where ABI is concerned, there we must use __u32 so that it does not clash with libc or user programs.
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.
It's "implementation" (kernel+libc+gcc) defined. It just means that gcc, the kernel, and libc have to be much more careful not to tread on each others toes.
The '__' have explicitly been put in by ISO in order to avoid conflicts between user-code and the standard libraries,
The "standard libraries" includes the syscall interface here. If the kernel types could not be prefixed with __, then what _should_ we prefix them with?
Furthermore, I think it's wise to convince the community that if not needed, integers should not be specified by any specific width.
That doesn't work for an ABI. If you switch compilers (or from 32-bit to 64-bit like from x86 to x86-64, you _must_ be able to specify certain widths for all the ABI numbers to preserve compatibility.
Cheers, Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-)
------END GEEK CODE BLOCK------
- 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/
