Re: Trouble with yytext

[Hans Aberg]

At 01:47 -0800 2001/12/07, ROLAND wrote:
>scomstr()
>{ if (logflag)
>   strcat(comstring,yytext);
>}

Here you concatenate the strings flex finds, instead of making new copies,
like when using strcpy, which looks funny to me.

Your code does not show any use of comstring, so I suggest you trace that
one (by hand, reading the code, or if that does not help, using a debugger).

Also, with ths construction, the life of the comstring is inly until the
next time Flex calls your scomstr(), which Bison will do for ever new token
it needs (inlcuind one possible lookahead token. Therefore it is better to
put the name into the Bison $ variable.

I do this by using C++ and
  class my_parser_type {
  public:
    std::string text;
  };
  #define YYSTYPE my_parser_type

I pick up these names in Flex say by
  %{
  #define get_text(pos, red) yylval.text \
    = std::string(yytext + (pos), yyleng - (pos + red))
  %}
  string_name      [[:graph:]]*
  %%
  "`"{stringname}"'"  { get_text(1, 1); return string_name; }

In Bison I then can use things like
  my_rule:
    token_1 '+' token_2 { $$.text = $1.text + $3.text; }

That is, every terminal/nonterninal has its own $n value.

The C experts can give you a C version of this.

>If there is not sufficient code to locate the problem,
>I can put some more code up...

Do the standard debugging first, tracing the life of the strings copied
into Bison, combining with the inputs you already gotten here; if that does
not help, return here.

  Hans Aberg