Re: RFC: enum instead of #define for tokens

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: 03 Apr 2002 19:13:05 +0200
> 
> I have seen patches from Jim Blandy to enable macros debugging in gdb.

Didn't know that.  That reduces the priority of using enums for bison.

> At home, I'm working on moving the engine from using shorts everything
> as indices into arrays to using actual pointers.

Doesn't this grow the table size by a factor of 4 on 64-bit hosts?
For typical parsers it wouldn't matter too much, but for parsers with
large tables this could be a big hit.  In particular, I worry that it
might hurt performance for dynamically linked modules, since the
dynamic linker might have to relocate all those pointers individually
when the module is loaded.  I recall that Ulrich Drepper went through
the GNU C library recently, replacing many pointers with integers,
precisely to improve performance this way.

With this in mind I would like to retain the option of using integers
in these tables, though the integers may need to be wider than they
currently are.  They could be narrower, too, to save space.

> My position, probably not very nice, is that this should not happen.
> Passing chars (wchars) as tokens is wrong.

I tend to agree, but I also think we're stuck with it, as POSIX
requires it and it's extremely common practice.  At best we can warn
in the documentation that it doesn't work if you change encodings
between the Bison run and the cc+runtime runs.

> I think only the latest was not installed: the one that removes the
> ability of growing the stack when %union is not used.

OK, you're talking about

http://mail.gnu.org/pipermail/bison-patches/2002-March/000760.html

I started to do this, and even checked in white-space changes to
bison-1_29-branch to make the merge go easier, but ran into one little
problem.  Should YYLTYPE_IS_TRIVIAL and YYSTYPE_IS_TRIVIAL be m4
thingamabobs in the main branch?  I'm a bit new to the m4ization of
Bison so it's not obvious to me how it should be done.