Re: [PATCH] test-suite: new preprocessor test case

[Hannes Eder <hannes@hanneseder.net>]

On Thu, Mar 19, 2009 at 7:26 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Thu, Mar 19, 2009 at 06:56:11PM +0100, Hannes Eder wrote:
>> Sparse currently fails on this test.
>
> It doesn't.  6.10.3p11: "If there are sequences of preprocessing tokens
> within the list of arguments that would otherwise act as preprocessing
> directives, the behavior is undefined."
>
> You are asking for identical nasal demons from two implementations, when
> it's not even promised that the same kind will fly on two invocations of
> the same implementation...
>
> Seriously, this is undefined behaviour *and* it's extermely hard to come
> up with self-consistent semantics for it.  Standard doesn't even try and
> implementations are doing whatever's more convenient at the moment.  Try
> to think of it and you'll come up with really ugly corner cases very fast.
>
> What we probably ought to do is a warning when such stuff happens.

Ok, I see. It's not a bug, but I wouldn't consider it as a feature either :)

When currently running sparse agains the current linux-next tree, a
lot of checks produce error messages like this:

include/linux/skbuff.h:381:9: error: expected preprocessor identifier

where gcc happily compiles it, because it preprocesses it differently

e.g.

$ gcc -E -P validation/preprocessor/preprocessor22.c
struct { int b; } a;;

comparing to

$ sparse -E
struct {
} a;;

This difference makes sparse at the moment less applicable to the
linux(-next) tree.

What can be done about that?

-Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html