lkml.org 
[lkml]   [2006]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subject"signed" versus "__signed__" versus "__signed" in arch-specific "types.h" files

    more annoying, nitpicky pedantry as i continue my tour of the kernel
    source. what is the rationale behind using the gcc keyword alias
    "__signed__" in many of the architecture-specific types.h files?

    the general form of many of those files is:

    ===================
    #ifndef __ASSEMBLY__

    /*
    * __xx is ok: it doesn't pollute the POSIX namespace. Use these in the
    * header files exported to user space
    */

    typedef __signed__ char __s8; <-- see?
    typedef unsigned char __u8;

    typedef __signed__ short __s16; <-- here, too, and so on.
    typedef unsigned short __u16;
    ...
    #ifdef __KERNEL__
    #ifndef __ASSEMBLY__

    typedef signed char s8; <-- but now, things change
    typedef unsigned char u8;

    typedef signed short s16;
    typedef unsigned short u16;
    ...
    ===================

    so the keyword alias "__signed__" is used early on in nearly every
    types.h file but, if __KERNEL__ is defined, the file falls back to
    just using "signed". (the use of "unsigned" is, of course, consistent
    throughout.)

    so, first, what is the rationale behind the use of "__signed__" in
    this context? and is there any reason that most of that content can't
    be centralized in a single arch-independent file and simply
    #include'd? for the most part, that general content looks identical
    regardless of the architecture. (in some cases, the files are
    *absolutely* identical, such as for arm and arm26, and one would think
    that a simple #ifdef or two could handle differing word sizes of the
    architecture.)

    however, having said all that, there are some puzzling exceptions to
    the above pattern. asm-ia64/types.h typedefs the second set based on
    the *earlier* typedefs:

    =============================
    ...
    typedef __signed__ int __s32;
    typedef unsigned int __u32;

    typedef __signed__ long __s64;
    typedef unsigned long __u64;

    /*
    * These aren't exported outside the kernel to avoid name space
    clashes
    */
    # ifdef __KERNEL__

    typedef __s8 s8; <-- like that
    typedef __u8 u8;

    typedef __s16 s16;
    typedef __u16 u16;
    ...
    =============================

    then there's asm-mips/sh/types.h, which *continues* to use
    "__signed__" after everyone else switches to merely "signed":

    =============================
    ...
    #ifdef __KERNEL__

    #define BITS_PER_LONG 32

    #ifndef __ASSEMBLY__


    typedef __signed__ char s8; <-- still using that gcc keyword alias
    typedef unsigned char u8;

    typedef __signed__ short s16;
    typedef unsigned short u16;
    ...
    =============================

    and, finally, there's include/asm-mips/types.h, which curiously
    introduces "__signed":

    =============================
    ...
    #ifdef __KERNEL__

    #define BITS_PER_LONG _MIPS_SZLONG

    #ifndef __ASSEMBLY__


    typedef __signed char s8; <-- ?????
    typedef unsigned char u8;

    typedef __signed short s16;
    typedef unsigned short u16;
    ...
    =============================

    is there any reason why a lot of this can't be standardized? it
    certainly looks like a lot of unnecessary duplication, interspersed
    with puzzling anomalies just to keep life interesting. :-)

    rday
    -
    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: 2006-10-29 12:05    [W:0.025 / U:0.384 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site