Re: trouble with flex++ bison++

[Hans Aberg]

At 16:05 +0200 2001/09/26, zze-Anticipip Ball001 FTRD wrote:
>Re: trouble with flex++ bison++

This is the Bison list, which I do not think have anything with flex++ or
bison++ to do.

>eqpt:
> Open eqpt_KW NUMBER NUMBER Close
>       {
>               printf("equipememt %s read successfully \n",$3);
>
>
>the parsed file looks like this :
>( eqpt 52 59 )
>( eqpt 62 69 )
>
>so this should print "equipement 52 read successfully" but i get "equipement
>52 59 ) read successfully"...
>and if i replace $3 with $4, i get "equipement 59 ) read successfully"...

This must be the absolutely most frequently asked question in this mailing
list:

Flex returns a char* to the text it found and temporarily ends it with '\0'
for processing. When Flex continues, it changes the '\0' back to what it
was before.

Thus, if you do not save away the text identified by Flex, the $n values
will show up to including the last identified text, unless the Flex buffer
has changed in the meantime, in which case the garbage will become even
more severe.

Under C++ I use:

In a C++ header:
  class my_parser_type {
  public:
    std::string text;
    ...
  };
  #define YYSTYPE my_parser_type
and in my .l file:
  %{
  #define get_text yylval.text = std::string(yytext, yyleng)
  %}
  ...
  %%
  [_[:alpha:]]([_[:alnum:]])*  { get_text; return identifier_key; }
  ...
thus making sure every text-segment is saved away in the $n.text field.

  Hans Aberg