Re: ‘void free(void*)’ called on unallocated object ‘yyssa’ [-Wfree-nonheap-object]

On 1/18/21 9:40 PM, Akim Demaille wrote: This is probably the kind of annoying warnings that Paul knows how to defeat. I would use pragmas, but maybe there is something more clever to do? Thanks in advance Paul! Unfortunately I don't know of anything clever. I haven't had a chance to use GCC

Re: new pacification suggestion?

On 11/20/18 12:01 PM, Akim Demaille wrote: -if (false) +if ((false)) This goes too far. If clang is warning about this sort of thing, then we should disable that clang warning. Again, compilers should be our servants, not our masters. ___

Re: Compiling Reverse Polish Calculator Example

On 10/31/2012 10:04 AM, Akim Demaille wrote: > How about this? Thanks, I pushed that into gnulib, with a minor tweak to the ChangeLog entry. ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison

Re: Compiling Reverse Polish Calculator Example

On 10/31/2012 08:46 AM, Akim Demaille wrote: > BTW, Paul, did you see my question about quotearg in this very thread? Sorry, no, I missed that. I suppose there should be a quote_mem or something like that. ___ help-bison@gnu.org https://lists.gnu.org/m

Re: Compiling Reverse Polish Calculator Example

On 10/31/2012 01:32 AM, Akim Demaille wrote: > I now also realize that maybe Bison should ignore these > BOM bytes. Or even propagate them to the generated files? I guess it'd be OK to ignore them but I wouldn't propagate them, as they're trouble. While we're on the subject of UTF-8, is Bison re

Re: help needed : old bison 1.2.8 not support parse-param/lex-param(cpio 2.09/2.10/2.11)

On 06/06/11 00:28, Mitchell Erblich wrote: > Looking for a known workaround if possible? Perhaps the simplest workaround would be to run Bison on a host that has an up-to-date Bison version, and then place Bison's output files into your version-control system. So long as you never change get

Re: should we deprecate %token-table?

On 01/09/2011 07:18 AM, Joel E. Denny wrote: > we document %token-table and yytname as deprecated > features and make Bison warn when %token-table is specified This seems the better course to me. The feature does not sound that well-thought-out; if nobody has the time to think it through and do

Re: Unnecessary(?) declaration of flex

On 08/14/10 17:17, John P. Hartmann wrote: > It really serves no purpose now. Why not remove it? It's not present in Bison 2.4.3, the current version, so it sounds like your request has already been granted. ___ help-bison@gnu.org http://lists.gnu.org/

Re: Growing stacks in C++

On 07/23/10 01:02, Hans Aberg wrote: > I recall Paul wrote the C skeleton, and one reason for not supporting > compile as C++ is that he did not want to work with C++, in > addition to being complicated somehow. Although I contributed to the C skeleton, I am not its original author; I believe that

Re: Bug in gnulib-tools prevents bison from bootstrapping

Bruno Haible <[EMAIL PROTECTED]> writes: > libtool.m4 also tries other workarounds: searching for an 'echo' program > in $PATH:/usr/ucb (but how is this better than 'cat'?) or using a built-in > 'print -r' command (which shells except ksh have this?) or using 'printf' > (is that portable nowadays?

Re: Bug in gnulib-tools prevents bison from bootstrapping

Eric Blake <[EMAIL PROTECTED]> writes: > POSIX requires that echo interpret backslash sequences. Actually, POSIX says that the behavior of 'echo' is implementation-defined if any of the arguments contain backslash, or if echo's first operand is -n. If the implementation supports the XSI extensio

Re: A polymorphic YYSTYPE for C++ (instead of the %union)

Thanks for the patch that you proposed in . I don't use C++, so you'll have to bear with me on some dumb questions. Perhaps some other contributor who knows C++ well can also chime in. * How much is this patch tied to Boost?

Bison test version 2.3a available

Bison test version 2.3a is now available. An important change in 2.3a is an experimental approach for replacing traditional Yacc prologue blocks. Here is the URL: ftp://alpha.gnu.org/gnu/bison/bison-2.3a.tar.gz Here are the MD5 and SHA512 checksums: 64e334f0a44cb3bb5e8be6b122c97d4f bison-2.3a

Re: problem with installation on cray x1e system

Thanks for reporting that, though as Hans Aberg notes it's better to report bugs to [EMAIL PROTECTED] I installed the following patch. By the way, I suggest you use Bison 2.3 rather than 2.1, as it should be a bit more reliable. 2006-07-12 Paul Eggert <[EMAIL PROTECTED]> *

Re: Porting Bison-2.0 to EBCDIC host

Hans Aberg <[EMAIL PROTECTED]> writes: > On 3 Jul 2006, at 22:45, RichAnderson wrote: > >> I am attempting to port Bison 2.0 to a machine which uses the EBCDIC >> character set. This version of bison wants to use itself to rebuild >> parse-gram.y. It shouldn't want to do that, unless you've modif

Bison 2.3 released

Bison version 2.3 has been released. This is mostly a porting and bug-fix release; the only change to user-visible behavior is to the YYRECOVERING macro in GLR grammars, as noted near the end of this message. Bison is a parser generator that is compatible with Yacc. Please see

Bison 2.2 released

Bison version 2.2 has been released. Aside from bug fixes, the most important changes in Bison 2.2 are in the new parser skeletons, used to generate parsers other than the traditional Yacc-like parsers. Among other things, the distribution terms now permit using Bison-generated parsers in nonfree

Re: Exceeded limits of %dprec/%merge?

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > Paul, this is a pretty obvious patch. > Should we slip it in before the release? Yes, please do that. Thanks for fixing the bug. ___ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison

Re: Multiple, different, %merge of a token sequence

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > One characteristic of the underlying problem is that Bison-generated > parsers are not careful about how they merge parse trees. This all sounds vaguely familiar. Have you read Scott et al, where they talk about the bugs in Tomita's original algorit

Bison test version 2.1a released

Bison test version 2.1a is now available. It contains mostly bug fixes for Bison 2.1, but there are few new features, notably in the area of better support for destructors. Our intention is to generate a new official release soon, based on feedback from this test version. Here is the URL: ftp:/

Re: incorrect yychar for unambiguous GLR

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > So, token numbers might be greater than 2^16 (int yyrawchar), Yes. It's longstanding practice that token numbers must be 'int' values. They have to be positive, as nonpositive values represent EOF. > the number of tokens cannot be greater than 2^16

Re: incorrect yychar for unambiguous GLR

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > I just noticed that this changes yyrawchar from int to short. I'm not > smart enough to know if this matters. yyrawchar is what yylex returned, right? If so, it must be int, since users can specify token numbers greater than 2**16. __

Re: incorrect yychar for unambiguous GLR

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > I'm taking a look at doing this. > > Before I start, are we sure? I noticed this in NEWS under 2.0: That was my failed attempt to standardize on "look-ahead" in 2004; see . My 20

Re: incorrect yychar for unambiguous GLR

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > Why must the lookahead token be maintained in two variables? Why not just > maintain yychar and invoke YYTRANSLATE whenever yytoken is needed? In the case of yacc.c, it's most likely efficiency: the desire to avoid reinvoking YYTRANSLATE. The trade

Re: incorrect yychar for unambiguous GLR

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > 3. I tend to follow the usual LaTeX and HTML coding style: one line break > after a sentence, two line breaks after a paragraph. This makes editing > much easier for me: it's easier to reorder sentences, and it's easier to > fix line-wrapping after

Re: incorrect yychar for unambiguous GLR

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > Also, the documentation likes to hyphenate `look-ahead'. Should it be > yylookAheadNeeds (capital 'A')? Is Paul Eggert the authority on this > issue? Naah, I just used my spelling checker, which didn't

Re: %destructor feedback

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > Providing the user with macros to combat compiler and lint warnings in > user code doesn't seem like a job that bison should take on. However, > providing the user with macros to combat bison warnings does. Thus, I > still vote that these should b

Re: Bison fast questions

"Cenzato Marco" <[EMAIL PROTECTED]> writes: > Do you know if the GNU Bison latest version (2.0 o 2.1) is MS Visual Studio > 2005 32/64 bit compatible? > > Or do you know someone that already worked on this? Please see and

Re: %destructor feedback

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > On Mon, 19 Dec 2005, Paul Eggert wrote: > >> Akim Demaille <[EMAIL PROTECTED]> writes: >> >> > A >> > simple macro that ignores its argument suffice to avoid the >> > complai

Re: %destructor feedback

Akim Demaille <[EMAIL PROTECTED]> writes: > Do we agree that: > > - we desire a warning about typed $n not used in the actions. Yes, that sounds reasonable. My assumption is that a missing action continues to be treated as { $$ = $1; }, so for missing actions Bison would warn about typed $2, $3,

Re: 'lint' fixes for Bison-generated parsers

Akim Demaille <[EMAIL PROTECTED]> writes: > Dare I suggest that > you might want to report this knowledge somewhere, e.g., autoconf.texi? > $0.02 from someone-who-did-nothing-but-suggests-others-to-do-more. Yes, that's a good idea, but to be honest I'm a bit swamped. > > -yysize_ove

'lint' fixes for Bison-generated parsers

I installed the following patch, which I hope fixes the YYUSE problems discussed in the "%destructor feedback" thread. 2005-12-09 Paul Eggert <[EMAIL PROTECTED]> Cleanups so that Bison-generated parsers have less lint. * data/c.m4 (b4_yydestruct_generate, b4_yys

Re: %destructor feedback

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > it seems that we need a band-aid that will at least stop the > bleeding we've actually *seen* so far. How about if we dump YYUSE entirely? We can put __attribute__ ((__unused__)) after any declaration that might be unused, and /*ARGSUSEDn*/ before an

Re: %destructor feedback

>>> Would (&(e)-1) solve that? >> >> No, because that's an invalid expression: it normally has undefined >> behavior, and 'lint' is within its rights to warn about it. > > Invalid seems like a strong word. You mean that some lint > implementations warn about pointer arithmetic on locals and params?

Re: %destructor feedback

"Joel E. Denny" <[EMAIL PROTECTED]> writes: >> #define YYUSE(e) (yyunused = &(e) && yyunused) >> then I suspect it will also run afoul of lint implementations that >> deduce that &(e) can never be null, and print a warning. > > Would (&(e)-1) solve that? No, because that's an invalid expression

Re: %destructor feedback

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > Did you try my static global variable solution? It worked for my > tests, but again it should probably be tested with other lints. If you're talking about this one: static int yyunused; #define YYUSE(e) yyunused = (int*) &(e) && yyunused then I

Re: %destructor feedback

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > That's fine with me, but what if someone declares a parse param as > const? Moreover, for C++, could an overloaded assignment with strange > semantics have an unexpected effect? Yes, probably. Sigh. I guess we need a better solution. _

Re: %destructor feedback

"Joel E. Denny" <[EMAIL PROTECTED]> writes: >> Does this work for you? >> >> #define YYUSE(v) ((v) = (v)) > > No, yysymprint() declares its yyvaluep param const. Let's remove the const, then. There's little point to declaring auto variables to be 'const'. __

Re: %destructor feedback

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > /opt/SUNWspro/bin/lint -V says: > >lint: Sun C 5.5 2003/03/12 That's a bit old, but not ancient. We should support it, if it's easy. Does this work for you? #define YYUSE(v) ((v) = (v)) >> How would you tell your 'lint' version to not output

Re: %destructor feedback

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > for the current YYUSE definition, I do see this warning: > >warning: logical expression always false: op "&&" As I understood it, this will happen with ancient lint implementations that don't support CONSTCOND comments; it shouldn't happen with ne

Re: %destructor feedback

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > What was wrong with the cast to void? It caused lint warnings. Please see these threads: http://lists.gnu.org/archive/html/bug-bison/2005-10/msg0.html http://lists.gnu.org/archive/html/bison-patches/2005-10/msg00022.html __

Re: %destructor feedback

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > However, I just noticed the current YYUSE definition doesn't allow the > argument to be a struct instance. Paul, Akim, is this intentional? Yes and no. If we could easily implement it with struct instances we would. But so far we haven't needed it,

Re: %destructor feedback

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > This thread started on help-bison. At some point, I CC'ed to > bug-bison. However, it eventually lost that CC and then picked it up > again. Could this be why you missed messages? Yes, that's it. It's such a long thread, though. If you're thinking

Re: %destructor feedback

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > Paul, I just looked through the ChangeLog. I believe you committed > the patch that made YYABORT and YYACCEPT invoke RHS destructors. Yes, I'm the guilty party. :-) I hadn't thought through these consequences. > As I see it, there would be one rul

Re: %destructor feedback

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > I prefer that the clean-up *not* happen automatically for either > YYABORT or YYERROR -- as in GLR parsing. Yes, that sounds more flexible. > If this is implemented, I believe that it should be implemented > consistently for all three cases: the user

Re: Bison 2.1 released

Tim Van Holder <[EMAIL PROTECTED]> writes: > It would be nice if you added a step > > - freeze messages and submit pot files to the TP one week before >release > > to the Bison release procedure. Thanks for the suggestion. I installed this: 2005-09-20 Paul E

Bison 2.1 released

Bison version 2.1 has been released. Bison is a parser generator that is compatible with Yacc. Please see for more info. Bison 2.1 is mostly a bug fix version since the last official release of Bison. Last-minute testing uncovered one possible problem in the

Bison 2.1 candidate tarballs available

I made tarballs for Bison 2.1 and have copied them to the following locations. If there are no obvious installation gotchas with these, I plan to install them at the official ftp.gnu.org location Monday. Please let me know if you run into showstopper problems. Thanks. ftp://alpha.gnu.org/gnu/bis

misleading diagnostics in Bison-generated parser trace

sions of bison for this test case. > This is a wild guess, but does this have something to do with the new > destructor call on the start symbol? If so, `Error' is a bit misleading. Thanks for mentioning this. Yes, it has something to do with that. I installed this patch: 200

Re: redundant merges for GLR

h, which doesn't quite match yours exactly but which uses the same idea. I also added the test case as you suggested. Thanks. 2005-08-21 Paul Eggert <[EMAIL PROTECTED]> * data/glr.c (yyresolveValue): Fix redundant parse tree problem reported by Joel E. Denny in <

Bison test version 2.0b available

Bison test version 2.0b is now available. It contains mostly bug fixes for Bison 2.0. Our intention is to generate a new official release soon, based on feedback from this test version. Here is the URL: http://www.cs.ucla.edu/~eggert/bison/bison-2.0b.tar.gz I've asked the GNU FTP upload gurus

Bison test version 2.0a released

Bison test version 2.0a is now available. It contains mostly bug fixes for Bison 2.0. Our intention is to generate a new official release soon, based on feedback from this test version. Here is the URL: ftp://alpha.gnu.org/gnu/bison/bison-2.0a.tar.gz Here is the MD5 checksum: 4304bcadc0115d0e

Re: %destructor and stack overflow

Marcus Holland-Moritz <[EMAIL PROTECTED]> writes: > Does the test part of my patch make any sense? Yes, I think so. Thanks. I checked everything in. ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison

Re: %destructor and stack overflow

Thanks for the patch, but I suspect the code patch isn't quite general enough, since a similar problem occurs if the user invokes YYACCEPT or YYABORT. How about this patch instead? 2005-05-01 Paul Eggert <[EMAIL PROTECTED]> * data/yacc.c (yyerrlab): Move the code that d

Re: %destructor and stack overflow

Marcus Holland-Moritz <[EMAIL PROTECTED]> writes: > When the parser detects a stack overflow, it should call > the cleanup actions defined via %destructor for all symbols > on the stack (and the symbol causing the overflow) before > it returns. Yes, that sounds right. Can you write and test a pa

Re: Bison and embedded systems

At 11:29 +0200 2005/04/25, Julian Gryffin wrote: >Bison is using dynamic memory in the C-file it built. Is there a >possibility to prevent it using dynamic memory? If by "dynamic memory" you mean "malloc or alloca", then yes, it's easy: #define YYSTACK_ALLOC(size) 0

Re: New BISON version for VMS

[EMAIL PROTECTED] writes: > I want to make a VMS install. Could you help me? This was discussed a couple of years ago. You might try reading , looking for "VMS", and contacting the people who expressed interest in VMS Bison ba

Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation

Paul Hilfinger <[EMAIL PROTECTED]> writes: > Actually, I believe that the Berne convention gives no standing > whatever to written copyright notices of this sort. Instead, if I > produce a copyrightable work, that work is protected by copyright > unless I take steps to make it otherwise. Yes, th

Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation

Hans Aberg <[EMAIL PROTECTED]> writes: > the output of a copyrighted program is rarely viewed as being > covered by the copyright of the program that made it. No, actually it's quite common. For example, if I run the traditional /usr/ccs/bin/yacc that is shipped with Solaris 9, the output file y

Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation

Sylvain Schmitz <[EMAIL PROTECTED]> writes: > It might have been true when these skeleton first appeared, but I > don't think it is any more, since both commercial and open source > implementations exist now. OK, let's solve the problem. The first step: could you please come up with a brief list