Re: Use of C99 int types

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux