Re: yacc.c: Extracting yysyntax_error

[Paul Eggert]

Akim Demaille <address@hidden> writes:

> I absolutely subscribe to point 3, but hey, really, when it comes to
> malloc and free, the point is somewhat exaggerated.

That's probably true, but I wanted to do it "right"....  Alas, I don't
think it's doable.

> Finally, as of point 2, given that there certainly many user
> allocations going on during the parsing,

Not always.  For example, the user code in getdate.y doesn't allocate
any memory dynamically (unless the input has a TZ="foo..." string
longer than 99 bytes, which is quite atypical).

Also, if there are user allocations, the user can arrange to have them
freed if a signal occurs; this is true even if YYMALLOC and YYFREE are
the system malloc and free.

> where are free to provide a new yyparse_free
> function to call the needed frees.

If I understand you correctly, this would be adding support to Bison
to free memory after a signal rather than requiring the user to keep
track of the allocated memory.  I suppose we could do something like
that (though it sounds a bit tricky).

> And last, until recently the Bison documentation made no commitment
> about memory cleaning in case of major changes in the program
> execution path.

It still doesn't make any promises re signals, does it?  :-)

> If you still feel it is not right to remove alloca support, how about
> post in 2.2's NEWS a huge banner asking "Do you depend on alloca?",
> and if there's no complaints, then 2.3 drops it?

I'd rather not go that route, if we can avoid it.  The current alloca
code works, and I think people still use it.  It's only 40 or so lines
of code in yacc.c; this is not a major maintenance burden.

Here are some examples of uses of alloca, or discussions about uses,
or desire to use alloca:

http://tug.ctan.org/tex-archive/graphics/sketch/sketch.y
http://mail.gnome.org/archives/gnome-hackers/2002-February/msg00017.html
http://cvs.sourceforge.net/viewcvs.py/firebird/firebird2/src/dsql/parse.y?rev=HEAD
http://cvs-digest.org/index.php?diff&path=koffice/kexi/doc/dev/CHANGELOG-Kexi-js&revision=1.167