Re: User Token Numbers

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: 09 Apr 2002 11:59:42 +0200
> 
> the user _has_ to write
> 
> %token error 257
> %token FOO   256

Yes, that's my reading of it, if they want it to be portable to all
POSIX implementations.  Admittedly the standard doesn't contain this
particular example.

I think it's OK for Bison to accept

  %token FOO   256
  %token error 257

as an extension.  I don't think a diagnostic is required when
accepting the extension.

> Should the token error be #define'd in the .h?

Unix yacc does not do that.  Like Bison, it puts `#define YYERRCODE
256' into the .c file, but nothing in the .h file.  With Unix yacc, if
you have `%token error 1000' in the input, this changes the .c #define
to be 1000 instead of 256, and it redoes the tables accordingly, but
the .h file stays the same.

The lexical analyzer is not supposed to return the error token, so
that probably explains why historically the token was not in the .h
file.  The standard does not explicitly prohibit putting `#define
YYERRCODE whatever' into the .h file, so I guess it'd be OK to do that
if there's a good reason to.

> Why does it matter to map error to 256?

My guess is that it's so that this:

%token FOO   257

will work even on single-pass implementations of yacc.  Otherwise, a
single-pass implementation that by default mapped error to 257 would
reject `%token FOO 257'.  Historically, grammars just used numbers
greater than 256, and my guess is that the POSIX authors wanted such
grammars to work on single-pass implementationms.