Synopsis - Issue Tracker

$ synopsis -p C /usr/include/assert.h
segfault

$ synopsis -p C /usr/include/ctype.h
bits/types.h: line 31: file 'stddef.h' not found
        included from /usr/include/ctype.h:28
ucpp returned error flag. ignoring error.
Segmentation fault

$ synopsis -p C /usr/include/alloca.h 
/usr/include/alloca.h: line 25: file 'stddef.h' not found
ucpp returned error flag. ignoring error.
ParseError: ('size_t',)

stddef.h is in /usr/include/linux/

Why not try testing the C parser on the linux kernel? :)

This is svn checkout from 0.8 branch.

Note that other files fail too, this is just a sample.

This was originally found by testing against the GGI 2.2.1 installed include files.

This is inside a ia32 chroot under amd64 debian sarge. 

Running synopsis with -v shows that ucpp is  adding -I /usr/include/linux and other dirs. However this path is not being used in synopsis itself, since an explicit application of the same string on the synopsis command line solves at least this problem.

Similarly, explicitly adding -I /usr/lib/gcc-lib/i486-linux/3.3.5/include solves other include problems.

Neil via synopsis issue tracker wrote:
> New submission from Neil <synopsis.tracker@kepier.clara.net>:
> 
> $ synopsis -p C /usr/include/assert.h
> segfault

rev:1657 should fix this. Can you please confirm ?

> $ synopsis -p C /usr/include/ctype.h
> bits/types.h: line 31: file 'stddef.h' not found
>         included from /usr/include/ctype.h:28
> ucpp returned error flag. ignoring error.
> Segmentation fault

I can't reproduce this. The segfault may be fixed with
the above checkin, but my ucpp doesn't complain about
stddef.h, which is the basic problem here. Can you
run with the '-v' flag to see the paths and macros
passed to ucpp ? Note that you may have a look into
the 'compiler emulator database', which is stored
in ~/.synopsis/parsers/cpp/emulator. (The content
should be self-explanatory.)

> 
> $ synopsis -p C /usr/include/alloca.h 
> /usr/include/alloca.h: line 25: file 'stddef.h' not found
> ucpp returned error flag. ignoring error.
> ParseError: ('size_t',)
> 
> stddef.h is in /usr/include/linux/
> 
> Why not try testing the C parser on the linux kernel? :)

Same here. WorksForMe. Sorry.

a) assert.h now gives no segfault with latest svn branch 0.8 :)

b) segfault is also fixed on ctype.h

c) running with -v on ctype.h gives lots of info, perhaps most important being:
 ucpp -I/usr/local/include -I/usr/lib/gcc-lib/x86_64-linux/3.3.5/include -I/usr/include
The /usr/lib/... patch is not installed within the chroot, so something is wrong there. All of my (recent) config/build/install commands were in the chroot and prefixed with linux32 (just in case), and a simple 'gcc -v' gives a first line of:
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
...so something is being automagically picked - wrongly :(
I looked in the file you mentioned and it is all x86-64 references. Something is looking at the cpu rather than the runtime?

Neil via synopsis issue tracker wrote:

> c) running with -v on ctype.h gives lots of info, perhaps most important being:
>  ucpp -I/usr/local/include -I/usr/lib/gcc-lib/x86_64-linux/3.3.5/include -I/usr/include
> The /usr/lib/... patch is not installed within the chroot, so something is wrong there. All of my (recent) config/build/install commands were in the chroot and prefixed with linux32 (just in case), and a simple 'gcc -v' gives a first line of:
> Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
> ...so something is being automagically picked - wrongly :(
> I looked in the file you mentioned and it is all x86-64 references. Something is looking at the cpu rather than the runtime?

Can you remove the emulator file and try again ?
I think I know what happens: the emulator file is a keeps an entry for each compiler
it finds, and it doesn't distinguish between 'gcc when run in chroot' and 'gcc native'.
The 'gcc' entry in your emulator file may stem from a run without chroot, and synopsis
now picks it up (wrongly) while in the chroot environment.

If that's the case I have to think about an alternative solution, as the compiler's
name (with absolute path) is clearly not enough to distinguish.
At least I should document this situation as something to be aware of, or avoid.

I removed the emulator file and I no longer get those include problems :) Note that using one file ~/.synopsis as a place for this could be a particular problem if I try and install both 32-bit and 64-bit compiled versions of synopsis - or should that 'just work'?

Continuing my quest to be able to run on all my system include files, I now get a problem with complex.h:
Syntax error : /usr/include/bits/cmathcalls.h:54: Error before '( double'
Syntax error : /usr/include/bits/cmathcalls.h:54: Error before '( double'
(and about 5 more pairs of errors)

This is in some fairly heavy preprocessor code to declare various incarnations of double/float/... functions. Let me know if this also breaks for you.

It appears the parse error stems from the Lexer
not knowing the _Complex keyword. It is used in
compounds such as 'float _Complex' in C99, and so
I told the lexer to ignore it. That's obviously
not a solution, but a quick workaround, as all
complex functions will now appear with an incorrect
signature. The alternative would be to add a new
token, as well as PTree node, and then let the
parser correctly handle it. While I believe this
is the way to go for the development branch, I
don't think it is worth putting it into the 0_8
branch.