Re: RFC: enum instead of #define for tokens

[Akim Demaille]

>>>>> "Paul" == Paul Eggert <address@hidden> writes:

Paul> Bison should choose the narrowest integer type that does the
Paul> job.

Agreed.


Paul> The ETA-10 is an old supercomputer (circa 1987 -- cooled by
Paul> liquid nitrogen!), 

Wow!  Could it levitate if asked to perform looping computations :)


>> I suppose we should use uintmax and Co., and AC_CHECK_SIZEOF.

Paul> I don't think we need to bother with uintmax_t.  The GNU coding
Paul> standards say (do I sound like a broken record? :-) "don't make
Paul> any effort to cater to the possibility that `long' will be
Paul> smaller than predefined types like `size_t'".  The items in
Paul> question all have to fit into memory, so "long" is wide enough,
Paul> and will work even on ancient K&R hosts that lack uintmax_t.
Paul> Also, 'long' is much easier to printf than uintmax_t is.

OK, sold for long.

>> Yep, I saw your post, but I have not tried.  As you sure it works?

Paul> I haven't tried it either, but if it doesn't work, Bison should
Paul> be fixed so that it does, since it's a POSIX requirement.
Paul> (I.e. it's a code bug not a doc bug.  :-)

You are referring to something like

%token error 666

right?  It seems to accept it (at least, it processes it, not tried
the parsers yet).



>> Wow!  Yes, I forgot there were tables using the tokens are entry.
>> Grrr, people should not rely on this `feature'.

Paul> I wasn't so much worried about people using yytranslate in their
Paul> own code (they deserve what they get; it's private).  

By `feature', I was referring to char-tokens, not yytranslate
actually.  Sorry :(

Paul> I was worried about how 'bison' would output a yytranslate that
Paul> will work on an EBCDIC host, even when 'bison' itself is running
Paul> on an ASCII host.  This issue is independent of the
Paul> pointer-versus-int issue.

Yep, we agree.