Josh Triplett wrote:
Michael Stefaniuc wrote:
Josh Triplett wrote:
Michael Stefaniuc wrote:
I'd love to see the results you get with Wine; in particular, I'd love to see
and fix any parse errors. Would you consider posting a build log somewhere
with latest Sparse from Git?
not sure if you are still interested but here is the output of
"building" wine with sparse:
http://people.redhat.com/mstefani/wine/download/wine+sparse-make.output.bz2
It was generated by "make clean; make > make.out 2>&1". Sparse runs
before every gcc call in the .c.o: make rule. As the wine build system
is verbose you'll see the exact command line used for sparse in the
above file.
Thanks for posting this. (Any particular reason you didn't post it to
linux-sparse? If not, feel free to fullquote and CC the list.)
Didn't want to spam the list with it. Couldn't imagine that somebody
wants to wade through 13 MB of Wine+sparse build log.
Some observations:
Thanks for your time looking at this.
-Wno-transparent-union should help; that would eliminate 318 warnings.
Don't pass -Wall to sparse unless you really mean it. cgcc filters it out for
a reason; just because you have -Wall in CFLAGS for GCC doesn't mean you want
-Wall for sparse. Sparse -Wall includes some warnings with high false
positive rates that you probably don't want.
Ok good to know. I went the easy way just duplicating the gcc command
line and replacing gcc with sparse and adding -D__i386___ as Wine won't
build without a processor type defined. I'm still trying to figure out
if sparse is useful (signal to noise ratio) for Wine. Wine has some
constraints (having to follow an existing old grown API; compatibility
with other C processors on non Linux OSes) that aren't a burden for the
Linux Kernel. E.g. a patch to move to C99 struct initializer was
recently rejected due to compatibility concerns with other C compilers.
In particular, -Wall includes -Wundefined-preprocessor. Avoiding that would
probably eliminate thousands of warnings about symbols like _MSC_VER (at
least, I would guess so without seeing the source of
/wine/include/winnt.h:283). With -Wundefined-preprocessor,
#if expression-containing-SYMBOL
will generate a warning if you haven't defined
SYMBOL, and I would guess that happens here. That said, you might want
something like:
#if defined(SYMBOL) && SYMBOL > number
I already looked at those and thought to fix them though I'm not sure if
it is worth. I would have to look at the C standard what that says. The
"fix" is trivial and should be compatible with any C compiler.
The undefined preprocessor identifiers from limits.h come from not using cgcc,
which defines them. Sparse should ideally define those itself. You can work
around the problem by using cgcc or by defining the symbols on the sparse
command line as cgcc does.
I'll do a run with cgcc tonight instead of sparse and check the difference.
Apart from that, the main culprit looks like the one error you already
mentioned and gave the test case for. I don't know the cause of that one yet.
As an error, it probably masks any warnings you might otherwise see.
Right. I've tried to run the test case in gdb but i see i need to learn
the inner workings of sparse before i can make sense of what i see.
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
Sr. Network Engineer Fax.: +49-711-96437-111
Red Hat GmbH Email: mstefani@xxxxxxxxxx
Hauptstaetterstr. 58 http://www.redhat.de/
D-70178 Stuttgart
-
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
