Hi there!

While working together with Peter Bigot on the MSP430x54xx and CC430 header 
files, we encountered a problem with the preprocessor.

Accidentally, the same identifier (macro) was defined in two different header 
files, both included from the main header file. The definitions were different, 
but the precompiler did NOT issue a redefinition warning.
It caused Peter some hours of debugging until he noticed that the (correct) 
definition ow WDTCTL0 from wdt_a.h had been overwritten by an older define 
inside common.h.

Somme more testing revealed that I can as many redefinitions of an identifier 
as I want without ever getting a warning, as long as these redefinitions take 
place in an included file. Even several ones one after another in 
the same included file.
I only get a warning, wenn I try to do a redefinition on the top file after the 
identifier had been defined in an included file.
Even if I do a define in the main object file and then include a file where the 
same identifier is redefined, I don't see any warning.

It looks like the redefine warnings are automatically and silently disabled 
when they do not take place in the top level file itself.

While this MIGHT be useful (it definitely wasn't in this case!) inside an 
include chain (where the builder of this chain should take care, if he ever 
notices), it will definitely be fatal if one includes dfferent header files for 
different separate modules which coincidentally both define an identifier/macro 
with the same name but different content. The last included header file wins 
and the program won't work. When the same module is called 
from a compilation unit where only one of the two is used, it will work again. 
This can drive a programmer crazy.

I didn't find any commandline parameter associated to this.

And more surprisingly, when testing the same constellation with my version of 
AVRGCC (which is based on GCC3.3.2 instead of 3.2.3) there IS a proper warning.

Does anyone know a solution to this? Is this intended behaviour? (I can't see 
why, and the usage of #undef in many mspgcc header files tells me that it isn't 
expected too)? is there a hidden commandlien switch to 
reactivate the warnings?
Or did I just miss something?

And no, I did not disable any warnings in the makefile, I use -Wall and added 
some more warnings explicitely.

Any ideas appreciated.

JMGross


Reply via email to