Re: yacc.c: Extracting yysyntax_error

[Akim Demaille]

>>> "Paul" == Paul Eggert <address@hidden> writes:

 > I'm not sure, but I'd guess the original motivation was:

 >  1.  Performance [...]

 >  2.  Avoid memory leaks when a C signal handler [...]

 >  3.  Name space cleanness [...]


 > As for (2), how are C++ programs supposed to prevent memory leaks in
 > such situations?  Does lalr1.cc handle this correctly?  (glr.c
 > doesn't, not that I'm tempted to modify it to handle this....)

C++ has much more logistics that C for this.  setjmp/longjmp is not
the actual model you are invited to use, rather exceptions do.  But
then proper destructors are called to reclaim the memory you lost.  I
confess I have no experience with signals in C++ though, and I guess
it is then pretty much the same as with C.

 > POSIX is fuzzy about whether (3) is required, which means it isn't
 > required (and therefore the POSIX yacc spec has a big hole).

Yes, the one about the semicolons :)

 > Solaris 10 yacc isn't name-space clean: it generates a y.tab.c that
 > includes <stdlib.h>, <string.h>.

Byacc, our real competitor IMHO, includes stdlib.h and uses
malloc/free.  It doesn't bother with alloca.


 > At the very least I suppose (3) should be documented better in
 > bison.texinfo.  Also, in reviewing gnulib <alloca_.h> I noticed that
 > there are some easy ports for Bison to other (non-GNU) compilers that
 > support alloca, and we might as well add them.

I still view this as a pure waste of time.  I admire every single
alloca patch of yours, but frankly, I think your time is more valuable
elsewhere.


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

Finally, as of point 2, given that there certainly many user
allocations going on during the parsing, I doubt you can just leave
like that.  And anyway, where are free to provide a new yyparse_free
function to call the needed frees.

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




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?