On Tue, 28 Jul 2009, Paul Mundt wrote:
>
> Yup, that seems to be what happened. I've never seen a warning about this
> with any compiler version, otherwise we would have caught this much
> earlier. As soon as the addr -> a rename took place it blew up
> immediately as a redefinition. Is there a magical gcc flag we can turn on
> to warn on identical definitions, even if just for testing?
No, this is actually defined C behavior - identical macro redefinitions
are ok. That's very much on purpose, and allows different header files to
use an identical #define to define some common macro.
Strictly speaking, this is a "safety feature", in that you obviously
_could_ just always do a #undef+#define, but such a case would be able to
redefine a macro even if the new definition didn't match the old one. So
the C pre-processor rules is that you can safely re-define something if
you re-define it identically.
Of course, we could make the rules for the kernel be stricter, but I don't
know if there are any flags to warn about it, since it's such a standard C
feature: the lack of warning is _not_ an accident.
It would be trivial to teach sparse to warn about it, of course. Look at
sparse/pre-process.c, function do_handle_define(). Notice how it literally
checks that any previous #define is identical in both expansion and
argument list, with:
if (token_list_different(sym->expansion, expansion) ||
token_list_different(sym->arglist, arglist)) {
and just make token_list_different() always return true (this is the only
use of that function).
I haven't checked if such a change would actually result in a lot of
warnings.
Linus
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
