In current gcc the order of options -D and -U is significant. The Single Unix(r)
Specification explicitly specifies that the order should not matter for the c89 
command. It reads (cited from version 2, which is ten years old):

-D name[=value]
Define name as if by a C-language #define directive. If no =value is given,
a value of 1 will be used. The -D option has lower precedence than the -U
option. That is, if name is used in both a -U and a -D option, name will be
undefined regardless of the order of the options. Additional
implementation-dependent names may be provided by the compiler. Implementations
support at least 2048 bytes of -D definitions and 256 names. 

I did not find a justification for the current gcc behavior. Searching revealed
a patch which implemented the behavior:
        http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00621.html
and two messages earlier that year which might be relevant:
        http://gcc.gnu.org/ml/gcc/2000-09/msg00673.html
        http://gcc.gnu.org/ml/gcc-patches/2000-08/msg01271.html
The original bug report was:
        http://gcc.gnu.org/ml/gcc-bugs/2000-08/msg00605.html
Neither message mentions a possible dependency to the unix specification.
Three years later the code went from the preprocessor to the frontend
        http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01432.html

I now have two questions:
1) Does anybody recall a discussion of this topic?
2) Is this a bug?

        Erwin

Reply via email to