Re: Use of C99 int types

[Renate Meijer]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/