Re: Ignore the cdecl and stdcall attributes for now.

[Michael Stefaniuc <mstefani@redhat.com>]

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@redhat.com
Hauptstaetterstr. 58            http://www.redhat.de/
D-70178 Stuttgart