Alan Burlison <[EMAIL PROTECTED]> writes:
>If an eval{} fails because of a snytax error, yydestroy is called on
>leaving the eval scope.  Unfortunately it does this:
>
>    yyval       = ysave->oldyyval;
>    yylval      = ysave->oldyylval;
>
>So anything that is in those 2 vars that hasn't made its way into the
>parse tree is lost forever.  I know this is an old problem, but I've
>been trying to think of a way to fix it.  Has anybody any suggestions? 

Hmm, so this is (kind of) akin to the regcomp fix - it is the "new" stuff
that is in yyl?val that should be free-d. And it is worse than that
as yyl?val is just the topmost the parser state, so if I understand correctly
it isn't only their current values, but also anything that is in the 
parser's stack (ysave->yyvs) at the time-of-death that needs to go.
And all of those use the horrid yacc-ish YYSTYPE union, so we don't know
what they are. Yacc did, it had a table which mapped tokens to types
which it used to get union assigns right. But byacc does not put that info
anywhere for run-time to use, so to get it right we would need to 
re-process perly.y and then look at the state stack as we popped it.

Yugh.

The way I usually do this is make YYSTYPE an "object" or something
like a Pascal variant record - which has a tag. 

This would not be easy to fix for perl5.
The best I can come up with is to make them all OP *, inventing 
special parse-time-only "ops" which can hold ival/pval/gvval values.

Then yydestruct could just free the ops in yylval and yyvs[],
freeing a gvalOP or pvalOP would do the right thing.

Almost certainly far more than we want to do to the maint branch.

The other way this mess is handled is to use a "slab allocator"
e.g. GCC used an "obstack" - this allows all the memory allocated 
since one noted a "checkpoint" to be free-d.
One could fake that idea by making malloc "plugable" and plugging 
it during parse to build a linked list or some such.

The down side of that scheme is that auxillary allocators tend to 
upset Purify like tools almost as much as memory leaks do.


-- 
Nick Ing-Simmons

Reply via email to