[antlr-interest] Problem with C target output on example C grammar

[Jim Idle]

> -----Original Message-----
> From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
> bounces at antlr.org] On Behalf Of Kamil Burzynski
> Sent: Tuesday, April 01, 2008 11:22 AM
> To: antlr-interest at antlr.org
> Subject: Re: [antlr-interest] Problem with C target output on example C
> grammar
> 
> Hello,
> 
> > To follow up on this, I did successfully download the .tgz of the
> > examples from Fisheye by right clicking the tgz link and selecting
> > "save as" from IE 7, but the .zip format seems to be corrupt.
> 
> Till now I was using http://www.antlr.org/download/examples-
> v3.1b1.tar.gz

OK - that version works for me. It may be a problem with the actual grammar rather than the target/code generator. 

> Now I had downloaded from fisheye, to the same result. This is no
> surprise, since in both cases external_declaration goes to
> function_definition without going through declaration, and
> function_definition in turn calls declarator and direct_declarator,
> while they require declaration to be on stack...

Hmm, that does sound like a problem with the grammar construction if there is a path through the rules that does not cause a scope to be stacked for the symbol table. Can you provide either your sample input or a small example, or confirm that you are using the default supplied input? Of course the example grammars are not meant to be rigorous examples of a parser for the language, more examples of how to use rules and so on, but they should not crash, at least not with the sample input. I will try the examples on Linux and make sure it isn't just something stupid here.

> 
> In meantime I have also managed to play a little with C target and
> while
> it is working, I am little worried, as for now I have found 2 problems.
> 
> a) I wanted to do some lex/yacc-type return values:

This isn't anything to do with the C target - you cannot do that in lexers.
 
> b) In some cases, by adding 'innocent' code whole thing crashes. Namely
> I only add:
> scope MyScope
> {
>       int foo;
> }
> to the working project based on C.g3pl (without using MyScope anywhere)
> and program crashes in very nasty way. 

Well, are you sure that you have recompiled everything correctly? If I get the input you are using, I can try to reproduce it. If you are using the supplied input without modification, then it should work because I tested it. It is possible that something has broken since I last tested it, but I usually test the examples before a snapshot, so I am surprised. If I could get anyone to volunteer to write some regression/unit tests then I could have more confidence ;-)

> Gdb says, that stack is corrupt
> (well, if I would do step-by-step analysis I would find it, probably),
> and valgrind says, that 'impossible happened' and internal valgrind
> error occurred ;) 

That sounds like something you have not quite compiled correctly to be honest, but it may be some sort of bug I suppose.

> The problem is that I was not able to reproduce it on
> original C.g3pl file from examples ;( I did not made any serious
> modifications yet, though I changed compilation mode slightly (whole
> parser is in .so now). Without this additional scope everything works
> fine, I can add my rules, actions, etc. 

I see, so you haven't done anything... except change the linking model ;-) How are you building the .so and did you relink your calling binary program with it or just rebuild the library and try to run with it. If the latter, then I suggest that that may well be your problem and the reason that stack is out of whack. Do you mean you can't reproduce either problem with the original example, or just this second one which I think is the way you are building it?


> And it seems, that I am alone
> here, since nobody will reproduce it.. ;(

Well, you haven't really given me an exact set of instruction with which to reproduce your problems! It wasn't until this email that I even knew you were using the correct version of the examples or that you were trying to put the parser in a shared library, and I still don't know for certain what input you are using :-) I will try this all out now and make sure though that at least the sample input works on Linux - watch for a patch if it does not. 

Jim