Hi, I was playing with sparse to see what it would accept, and I was actually surprised at how many "obviously wrong" constructs it accepted. Because sparse is supposed to warn about this, isn't it? Or is there a policy not to warn about things that gcc already rejects? If that were the case, I believe it would reduce the overall usefulness of sparse. (I say "obviously wrong" because I don't see how they can be valid, but I might of course be mistaken :-)) Anyway, here are my test cases: ==> const-void.c <== /* "const void" has no meaning. */ const void f(void); ==> extern-parameter.c <== /* "extern" in parameter declaration has no meaning. */ void f(extern int x); ==> inline-parameter.c <== /* "inline" in parameter declaration has no meaning. */ void f(inline int x); ==> inline-typedef.c <== /* "inline" is in front of "typedef". Is this equivalent to * "typedef inline int t"? Even so, it doesn't make sense to make variables * inline. */ inline typedef t; ==> inline-variable.c <== /* "inline" for variables has no meaning. */ static inline int x = 0; ==> typedef-collision.c <== /* Two types with the same name. The second one is used, but should it * be allowed? */ typedef char t; typedef int t; static t my_t = 0; ==> typedef-parameter.c <== /* "typedef" in parameter declaration has no meaning. */ void f(typedef x); None of these produce errors or even warnings when they are run through sparse. I probably won't get around to fixing these myself since I'm not that familiar with sparse internals. This is just a heads up :-) Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 -- 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
