Non-ascii host [was: Re: [PATCH] PR java/10253 (""+0), version 2]

[Eric Blake <ebb9 at email dot byu dot edu>]

My initial quick glance shows that parse.y is pretty host independent. 
Most literals in that file are for error messages (and those should 
remain literals to avoid outputting gibberish).  But I agree that other 
portions of the gcj suite, like the lexer or gij, use a fair share of 
literals that would break compilation on non-ascii hosts.

So should I worry about these lines in parse.y, in merge_string_cste 
that I just patched? Or should I just drop the issue for now?
      static const char *const boolean_true[] = "true";

To be host independent, something like this would be needed:
      static const char boolean_true[]
        = {'\164', '\162', '\165', '\145', '\0'};


Jikes' approach is to predefine all characters and strings needed for 
keywords or output with machine-independent values in a header file (for 
example, enum {U_a = '\141'}; is the unicode value of 'a', const char 
U8S_Code[] = {U_C,U_o,U_d,U_e,U_NULL}; is a UTF-8 string, for the "Code" 
attribute stuck in a .class file constant pool). Proper use of such 
constants then assure that a non-ascii host won't mess up.

Personally, I've never used a non-ascii host, to see what would break on 
either gcj or jikes, so I am not really in a position to explore the 
issue further at this time.  For that matter, ARE there any non-ascii 
hosts that gcc currently runs on?  The GCC manual, 
http://gcc.gnu.org/onlinedocs/gccint/Portability.html#Portability, does 
not mention anything about ASCII but does claim that GCC should not 
contain machine dependent code.

Tom Tromey wrote:
> There are a bunch of assumptions along these lines in the lexer (and
> perhaps other places, I'm not sure).  Some of these are obvious
> (search for char literals), but also `java_keyword' would need to be
> fixed.
>
> If people are actively using EBCDIC hosts, we at least need a PR, and
> at most a plan for fixing this.  I'd prefer we not fix this by using
> \0xx everywhere we need a character constant.
>
> Tom


--
This signature intentionally left boring.

Eric Blake             ebb9 at email dot byu dot edu
  BYU student, free software programmer