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
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
Early imperative languages like FORTRAN and BASIC are marked by a large number
of keywords. In my bison code I have pages of %token lines for PRINT and INPUT
etc, which I then replicate in my flex with something like PRINT { return
PRINT; }. This seems wasteful and just the thing the system shou
On Mittwoch, 30. Dezember 2020 07:48:18 CET Akim Demaille wrote:
> > Looking at the generated foo.tab.c file for my parser, I see these
> >
> > macros:
> > #define YYACCEPTgoto yyacceptlab
> > #define YYABORT goto yyabortlab
> > #define YYERROR goto yyerrorlab
>
recap: me looking for a working glr solution:
>> Alright. I took out the 'api.value.type union' and put in:
>> %union {
>> gen::index_t index;
>> merge_t merge; // A struct to hold my merge info
>> }
>>
>> All my tokens are of the form: %token tok1 tok2 tok3 ...
>> All my rules are of th
