Re: yytoknum and YYPRINT

[Tim Van Holder]

On Mon, 2002-11-18 at 10:23, Akim Demaille wrote:
>  Tim> It's just that we had a function in most our .y files that
>  Tim> returned a given token's name (for use in internal tracing etc).
>  Tim> Using yytoknum and yytname for this worked quite nicely.
> 
> Can you show us the actual code?  Is it the feature that you need, or
> really these two guys?

Sure:

const char*
conv_cobol_token(const unsigned short token)
{
  if (token == 0)
    return "t_nil";
  else {
  const unsigned short* toknum  = yytoknum;
  const char* const*    tokname = yytname;
  unsigned long         ntokens = sizeof(yytoknum)
                                / sizeof(unsigned short);
    while (toknum != NULL && ntokens-- > 0) {
      if (*toknum == token)
        return *tokname;
      ++toknum;
      ++tokname;
    }
    warning (0, _("{%s} Could not convert token `%u' to a string"),
             __FUNCTION__, token);
    return _("<error>");
  }
}

This stems from the fact that our tools store the token as part of the
information in the parse tree (a design flaw, but one that is almost
impossible to fix in the existing code - all newly built programs no
longer use tokens for anything other than lexer-parser communication).

I kinda figured that the -k option implied that those tables became
available to the user.  yytname is useless when all you have is the
globally visible token number, instead of bison's internal value; you
need yytoknum for that mapping.

>  Tim> But now yytoknum's visibility depends on YYPRINT being defined;
>  Tim> this seems to make little sense to me, 
> 
> Nope, it does: that's the only place where we need this information.

Well yes, but if it was intended to be available to the user, that would
not have been a valid reason.

-- 
Tim Van Holder <address@hidden>
Anubex