Re: Ignore the cdecl and stdcall attributes for now.

[Josh Triplett <josh@freedesktop.org>]

[-- Attachment #1: Type: text/plain, Size: 4731 bytes --]

Michael Stefaniuc wrote:
> 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.

cgcc will define the processor type too.

I highly recommend trying a build with CC=cgcc.  You can then pass sparse
flags in CFLAGS, and cgcc will filter them out before calling CC; you can
also specify CHECK="sparse -Wfoo -Wno-bar" if you prefer not to change
CFLAGS.

> I'm still trying to figure out 
> if sparse is useful (signal to noise ratio) for Wine.

It will likely take some time and Sparse modifications in order to parse
Wine; however, I want Sparse to handle as much code as it can, not just
Linux.  I appreciate you trying it on Wine; I think working on this will
help both Wine and Sparse.

> 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.

I just committed support for a -Wno-old-initializer flag to turn off the
sparse warning on non-C99 initializers.

>> 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 C standard says that any undefined preprocessor symbol in an #if or #elif
becomes 0.  (See http://c0x.coding-guidelines.com/6.10.1.html , item 1859).
Sparse warns when doing so if you use -Wundefined-preprocessor; you might or
might not want that.

I just suggested including defined(SYMBOL) because you might not expect the
behavior that "#if FOO_VER < number" will pass and include the enclosed code
with FOO_VER undefined.

>> 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.

Thanks!

>> 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.

Feel free to ask if you need help or if you think you might have a theory.

- Josh Triplett


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]