--- Begin Message ---
- To: Branden Robinson <branden@debian.org>
- Cc: Jan Nieuwenhuizen <janneke@gnu.org>
- Subject: The BIG_ENDIAN problem
- From: Niels Ferguson <niels@ferguson.net>
- Date: Fri, 27 Sep 2002 17:11:31 +0200
- Message-id: <3.0.3.32.20020927171131.0097c5b0@pop.xs4all.nl>
- In-reply-to: <20020923234442.GO14540@deadbeast.net>
- References: <3.0.3.32.20020923183958.00998660@pop.xs4all.nl> <3.0.3.32.20020923040224.00978eb0@pop.xs4all.nl> <3.0.3.32.20020923010324.00974100@pop.xs4all.nl> <20020922194234.GA14540@deadbeast.net> <3.0.3.32.20020923010324.00974100@pop.xs4all.nl> <3.0.3.32.20020923040224.00978eb0@pop.xs4all.nl> <3.0.3.32.20020923183958.00998660@pop.xs4all.nl>
Dear Branden,
Jan Nieuwenhuizen, a friend of mine here in the Netherlands, had another
look at the BIG_ENDIAN naming conflict. Here is what he found.
===================================================
15:29:55 fred@peder:~/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 fred@peder:~/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:31:24 fred@peder:~/usr/src/twofish-clib
$ dpkg -S /usr/include/string.h
libc6-dev: /usr/include/string.h
15:33:04 fred@peder:~/usr/src/twofish-clib
$ dpkg -S /usr/include/bits/string2.h
libc6-dev: /usr/include/bits/string2.h
15:33:13 fred@peder:~/usr/src/twofish-clib
===================================================
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, niels@ferguson.net, phone: +31 20 463 0977
PGP: 3EC2 3304 9B6E 27D9 72E7 E545 C1E0 5D7E
--- End Message ---