>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> 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.
