Messages in this thread | | | From | Kyle Moffett <> | Subject | Re: Use of C99 int types | Date | Tue, 5 Apr 2005 07:27:49 -0400 |
| |
On Apr 05, 2005, at 05:23, Renate Meijer wrote: >> 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 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/
| |