I'm getting messages from Bison that aren't even listed on the internet.

on and $ after it, so the 170 results are very generic, very few have '$... in them, mostly '%..., and none of them actually offers any kind of explanation. If you've any ideas on the above, I'd be pleased to look at any comment. I'll be chasing the forum(s) with this a

When data types must be read in strict sequence?

Thanks for your help. I have attached the latest listing of the program in question. When I run Bison now, then the messages I get from that are... parse.y: warning: 8 useless nonterminals and 30 useless rules parse.y:52.1-7: fatal error: start symbol grammar does not derive any sentence The par

What does error message "fatal error: start symbol grammar does not derive any sentence" mean?

Thanks for your help. I have attached the latest listing of the program in question. When I run Bison now, then the messages I get from that are... parse.y: warning: 8 useless nonterminals and 30 useless rules parse.y:52.1-7: fatal error: start symbol grammar does not derive any sentence I believ

My Flex/Bison process is stalling when trying to read a left bracket.

The processes proceed well until the compiler generated encounters an opening bracket. I get the following output... This is the cln file Aug 2 2009 [sudo] password for joe: removing lex.yy.c rm: cannot remove `lex.yy.c': No such file or directory removing lex.yy.o rm: cannot remove `lex

Reporting malloc failure in actions

Hi, is there a recommended way to fail parsing when an action cannot allocate memory? I could use YYABORT, but the caller could mistake this for a problem in the input, when it's really an internal problem. Looking at the generated foo.tab.c file for my parser, I see these macros: #define

Re: Reporting malloc failure in actions

Akim Demaille wrote: > > if (!(bla = malloc(n))) > > goto yyexhaustedlab; > > I guess most people just fail here, and don't even try to recover from > memory exhaustion. Out of curiosity: do you really manage to keep > your program working after you've run out of memory? In my cas

Re: Reporting malloc failure in actions

Christian Schoenebeck wrote: > When it comes to error handling in Bison/Flex user actions, I would > recommend to always define and use your own macros and/or functions in > user actions instead of calling Bison/Flex ones directly. That safes > you refactoring work over time. Makes sense, I'll do

GLR causing warning about _Noreturn in C99

When I enable %glr-parser, it generates two functions marked with _Noreturn: _Noreturn static void yyFail (yyGLRStack* yystackp, void *scanner, const char* yymsg) _Noreturn static void yyMemoryExhausted (yyGLRStack* yystackp) Since my compile flags include -std=c9

Re: GLR causing warning about _Noreturn in C99

Akim Demaille wrote: > Thanks for the report. No problem. Looks like I should have posted it to the bug-bison list though, rather than here. Oops. > > /* The _Noreturn keyword of C11. */ > > #ifndef _Noreturn > > ... > > This piece of code comes from gnulib (well, it was copied-past

Re: GLR causing warning about _Noreturn in C99

Joe Nelson wrote: > Ah, in that case I'll report the bug upstream in gnulib. When they fix > it we can copy their updated code. OK, they fixed the bug in gnulib: https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=077ffc1e416a6be980dd45979547201e572962f6 Here's the upd

Re: GLR causing warning about _Noreturn in C99

Akim Demaille wrote: > I adjusted this patch for Bison. Could you please try this tarball > before I install the appended patch into master? Thanks in advance. Build the version from source, and used it to generate my parser. It worked great, no warnings. :)

More elegant way to parse this?

I wrote a parser for Roman numerals, and it seems to work for whatever numbers I throw at it. However, there are two things I don't like: a bunch of s/r conflicts, and the double recursion "number number". Anyone know a way to keep it concise but avoid the warnings and inefficiency? Parser ==

Bison advises that a variable 'expr' I use isn't declared.

The union in which the type for the expr variable is declared is... %union {/* this becomes yylval ! */ int val; /* GMP type required here. */ struct symtab *symp; } The declaration of the variable is... %type expr/* determines that expr is an int, though

Correct makefile for a bison/flex compilation

I presently have a compiler to write with Flex and Bison. I have a lex.l file, and a parse.y in which there are no conflicts. I also have a symtable.h included. I have a makefile as follows... project: parse.tab.o lex.yy.o echo

Re: Reporting malloc failure in actions

Christian Schoenebeck wrote: > > #ifdef YYNOMEM > > /* newer bison version */ > > YYNOMEM; > > #else > > /* older bison (undocumented feature) */ > > goto yyexhaustedlab; > > #endif > > You would be dealing with internals, but AFAICS that internal label > already exists for decades