Re: Use of C99 int types

[Richard B. Johnson]

On Mon, 4 Apr 2005, 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.  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.  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.
>
> Cheers,
> Kyle Moffett

Actually not. I think the whole point of the C99 (POSIX integer)
types is to avoid problems like you cite. Nobody should be using
types that begin with an underscore in user-code anyway. That
name-space is reserved.

One cannot just use 'int' or 'long', in particular when interfacing
with an operating system. For example, look at the socket interface
code. Parameters are put into an array of longs and a pointer to
this array is passed to the socket interface. It's a mess when
converting this code to 64-bit world. If originally one used a
structure of the correct POSIX integer types, and a pointer to
the structure was passed, then absolutely nothing in the source-
code would have to be changed at all when compiling that interface
for a 64-bit machine. The continual short-cuts, with the continual
"special-case" hacks is what makes porting difficult. That's what
the POSIX types was supposed to help prevent.

That's why I think if there was a stdint.h file in the kernel, when
people were performing maintenance or porting their code, they
could start using those types.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
                 98.36% of all statistics are fiction.
-
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/