lkml.org 
[lkml]   [2005]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Use of C99 int types
    Date
    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/

    \
     
     \ /
      Last update: 2005-04-06 13:31    [W:0.024 / U:120.476 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site