help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: help-bison Digest, Vol 30, Issue 15


From: Steve Murphy
Subject: Re: help-bison Digest, Vol 30, Issue 15
Date: Sun, 23 Apr 2006 22:39:00 -0600

On Sun, 2006-04-23 at 10:02 -0600, Joel Denny wrote:

> On Sat, 22 Apr 2006, Steve Murphy wrote:
> 
> > BTW-- I got a segfault when I fed bison this nonsense:
> > 
> > %destructor { free($$);} else {printf("Cleanup destructor called for str
> > \n");} } word word_list goto_word word3_list includedname
> 
> I've reproduced this in 2.1a, but it seems to be fixed in the latest CVS 
> sources.  If this is a significant problem for you, you might try the CVS 
> sources, or just wait for 2.2.  Paul, Akim, any idea on when 2.2 will be 
> released?
> 

This is not a critical issue. I immediately suspected that I was
careless in my editing, and fixed the line. But I know that everyone's
goal is to avoid segfaults. And it's kinda ironic that that a parser 
generator has weaknesses in parsing bad input... The important thing is
that it gets addressed by and by, no hurry on my part!




> > I missed the part about the start token, which was my downfall. So I
> > removed it from the %destructor list.
> 
> Be careful: the start symbol is not a token.

True. Pardon the loose terminology!

> 
> There are two possibilities here:
> 
> 1. The start symbol does not appear on the RHS of any other production.  
> In this case, you can't access its semantic value later, so why set it at 
> all?

True. Only reasons I can think of, are the usual reasons for doing
unneccessary things: convention, habit, consistency, you get a warning
if don't,  etc.

> 
> 2. The start symbol does appear on the RHS of another production, and so 
> you can *sometimes* access its semantic value later.  If you remove its 
> %destructor, you might have memory leaks.  One way to keep the %destructor 
> but avoid destroying the value at the top of the tree is to create a new 
> start symbol that produces the original start symbol.

OK.

If the start symbol is going to be passed to yydestruct() come rain or
shine (if so specified in a %destructor), it might be meaningful to know
which it is... in other words, I haven't tried to understand the
algorithm, but firstly, can an error result in the start symbol being
tossed? If so, is there any way for yydestruct to determine whether the
start symbol is being tossed for Cleanup reasons, or for Error reasons?
(I think there could be situations where it might matter...).

murf






reply via email to

[Prev in Thread] Current Thread [Next in Thread]