[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: enum instead of #define for tokens

From: Paul Eggert
Subject: Re: RFC: enum instead of #define for tokens
Date: Fri, 5 Apr 2002 11:54:57 -0800 (PST)

> Date: Fri, 5 Apr 2002 16:59:18 +0200
> From: Hans Aberg <address@hidden>
> At 02:37 -0800 2002/04/05, Paul Eggert wrote:
> >I was worried about how 'bison' would output a yytranslate that
> >will work on an EBCDIC host, even when 'bison' itself is running on
> >an ASCII host.  This issue is independent of the pointer-versus-int
> >issue.
> Is this cross compiler problem common?

It depends on what you mean by "common".  If you use EBCDIC it's
common.  If you use the non-ASCII part of ISO 8859-1 and are
collaborating with someone else who's using some other character set
in the ISO 8859 series, it's common.  Assuming Bison supports
multibyte character sets properly (isn't that how we got started on
this thread?), a similar problem occurs with the non-ASCII parts of
UTF-8, EUC-JP, shift-JIS, etc.

Most people stick to plain ASCII in Bison grammars, because they don't
want this hassle; so the problem is not common now.  But this is due
to a drawback of the current Bison implementation; it's not a
desirable feature per se.

> -- Note that the problem does not exist for Unicode UTF-n encodings

Only if everyone agrees to use that particular extension to ASCII.
Similarly, the problem doesn't occur for EUC-JP, but only if everyone
agrees to use EUC-JP.

> Note that one may want to use the yytranslate[] table as is if one is using
> distributed programming, say a WWW-browser reading ASCII on an EBCDIC
> computer.

Yes, that's the sort of scenario I was worried about.  I doubt whether
the problem is limited to yytranslate, though.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]