Re: [RFC/PATCH] mm: Pass virtual address to[__]p{te,ud,md}_free_tlb()

[Linus Torvalds]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/