bug-glibc
[Top][All Lists]
Advanced

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

glibc-2.3.1 defines BIG_ENDIAN: naming conflict


From: Jan Nieuwenhuizen
Subject: glibc-2.3.1 defines BIG_ENDIAN: naming conflict
Date: Wed, 23 Oct 2002 16:34:46 +0200
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu)

Niels Ferguson, a friend of mine, received bug reports from GNU/Linux
users for his portable twofish library
(http://niels.ferguson.net/code/TwofishClib.html) and asked me to look
into it.

It turned out that glibc (2.3.1) defines the macro BIG_ENDIAN when
string.h or memory.h is included, and gcc optimization is switched on.

The C99 draft standards do not seem to allow this.

Greetings,
Jan.


Details:

    15:29:55 address@hidden:~/usr/src/twofish-clib
    $ gcc-3.2 -c -o twofish.o -O1 -g twofish.c
    twofish.c:214:1: warning: "BIG_ENDIAN" redefined
    In file included from /usr/include/bits/string2.h:52,
                     from /usr/include/string.h:360,
                     from /usr/include/memory.h:30,
                     from twofish.c:156:
    /usr/include/endian.h:47:1: warning: this is the location of the previous
    definition
    15:30:44 address@hidden:~/usr/src/twofish-clib
    $ head -400 /usr/include/string.h | tail -40
       declare the function if the `basename' macro is available (defined
       in <libgen.h>) which makes the XPG version of this function
       available.  */
    extern char *basename (__const char *__filename) __THROW;
    # endif
    #endif


    #if defined __GNUC__ && __GNUC__ >= 2
    # if defined __OPTIMIZE__ && !defined __OPTIMIZE_SIZE__ \
         && !defined __NO_INLINE__ && !defined __cplusplus
    /* When using GNU CC we provide some optimized versions of selected
       functions from this header.  There are two kinds of optimizations:

       - machine-dependent optimizations, most probably using inline
         assembler code; these might be quite expensive since the code
         size can increase significantly.
         These optimizations are not used unless the symbol
            __USE_STRING_INLINES
         is defined before including this header.

       - machine-independent optimizations which do not increase the
         code size significantly and which optimize mainly situations
         where one or more arguments are compile-time constants.
         These optimizations are used always when the compiler is
         taught to optimize.

       One can inhibit all optimizations by defining __NO_STRING_INLINES.  */

    /* Get the machine-dependent optimizations (if any).  */
    #  include <bits/string.h>

    /* These are generic optimizations which do not add too much inline code.  
*/
    #  include <bits/string2.h>
    # endif
    #endif

    __END_DECLS

    #endif /* string.h  */


    15:58:11 address@hidden:~/usr/src/twofish-clib
    $ dpkg -S /usr/include/endian.h 
    libc6-dev: /usr/include/endian.h
    16:12:23 address@hidden:~/usr/src/twofish-clib
    $ dpkg --status libc6-dev
    Package: libc6-dev
    Status: install ok installed
    Priority: standard
    Section: devel
    Installed-Size: 11548
    Maintainer: GNU Libc Maintainers <address@hidden>
    Source: glibc
    Version: 2.3.1-3


Niels Ferguson writes:

    It is clear that the libc library defines the BIG_ENDIAN macro if
    optimisations are switched on. I don't have the full C99 standard, but I
    did find the final committee draft on the web. It states in the chapter
    that defines all the different header files:

    =====

    7.1.3 Reserved identifiers

    1 Each header declares or defines all identifiers listed in its
    associated subclause, and optionally declares or defines identifiers
    listed in its associated future library directions subclause and
    identifiers which are always reserved either for any use or for use as
    file scope identifiers.

    * All identifiers that begin with an underscore and either an
    uppercase letter or another underscore are always reserved for any
    use.

    * All identifiers that begin with an underscore are always reserved
    for use as identifiers with file scope in both the ordinary and tag
    name spaces.

    * Each macro name in any of the following subclauses (including the
    future library directions) is reserved for use as specified if any of
    its associated headers is included; unless explicitly stated otherwise
    (see 7.1.4).

    * All identifiers with external linkage in any of the following
    subclauses (including the future library directions) are always
    reserved for use as identifiers with external linkage.143)

    * Each identifier with file scope listed in any of the following
    subclauses (including the future library directions) is reserved for
    use as macro and as an identifier with file scope in the same name
    space if any of its associated headers is included.

    2 No other identifiers are reserved. If the program declares or
    defines an identifier in a context in which it is reserved (other than
    as allowed by 7.1.4), or defines a reserved identifier as a macro
    name, the behavior is undefined.

    3 If the program removes (with #undef) any macro definition of an
    identifier in the first group listed above, the behavior is undefined.

    =====

    Which I read to state that the library isn't allowed to define something
    called BIG_ENDIAN. (I looked at all the other sections referred to, but
    none allow BIG_ENDIAN to be defined.)

    My conclusion is that the libc library is at fault.

    I've asked Jan to file a bug report.

    Kind regards,

    Niels
    =====
    Niels Ferguson
    PGP: 3EC2 3304 9B6E 27D9  72E7 E545 C1E0 5D7E

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]