lkml.org 
[lkml]   [2005]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Use of C99 int types
    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-04-06 13:31    [W:4.081 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site