Re: yacc.c: Extracting yysyntax_error

[Akim Demaille]

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

 >> [we] 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).

I mean memory allocated by Bison itself, not memory the user
allocated.  Pure parsers could use a struct (very much like lalr1.cc
does) with all the field in there, and we could provide a more
complete interface to users of the pure parser that gives them the
means to reclaim the memory if they really wish to be signal-proof.

 >> 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?  :-)

Good point, and happy to see you're not about to carve into stone
right now :)


 > 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.

I would love to have a tool that query a CVS server to track the
number of times a line was changed, coz' I'd bet that the alloca
paragraphs of yacc.c would be ranked quite high, independently of its
(current) length.  Counting the number of complaints/problems would
also incriminate it.

 > 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

This URL shows they use it only on Windows...

#ifdef _WIN32
#include <malloc.h>
#define alloca _alloca
#define YYSTACK_USE_ALLOCA 1
// turn of warning about unused goto label in bison skeleton

#pragma warning(disable:4102)
#endif


 > http://mail.gnome.org/archives/gnome-hackers/2002-February/msg00017.html

They use alloca, but they don't say why.

 > http://cvs.sourceforge.net/viewcvs.py/firebird/firebird2/src/dsql/parse.y?rev=HEAD

// Using this option causes build problems on Win32 with bison 1.28
//#define YYSTACK_USE_ALLOCA 1

Hum... Doesn't show much (but an aging connection with the previous
point).

It also includes

/* Make bison allocate static stack */
#define YYINITDEPTH 2048

which reminds me that, yes, in the past we did have a statically
allocated stack...

 > http://cvs-digest.org/index.php?diff&path=koffice/kexi/doc/dev/CHANGELOG-Kexi-js&revision=1.167


#define YY_NO_UNPUT
#define YYSTACK_USE_ALLOCA 1
#define YYMAXDEPTH 255

Short stack!  But alloca'ted, agreed.