*PUSH* Sorry for replying to my own message, but does nobody have an idea or even a comment about this issue?
JMGross ----- Ursprüngliche Nachricht ----- Von: JMGross An: MSPGCC mailing list, Gesendet am: 14 Jan 2010 20:02:51 Betreff: [Mspgcc-users] Possible preprocessor bug 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
