On Thu, Mar 19, 2009 at 7:26 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
