Re: [patch, RFC] Fix PR 30389 - ASCII functions

[Brooks Moses <brooks dot moses at codesourcery dot com>]

Thomas Koenig wrote:
> this is a proposal for dealing with PR 30389, or rather with the
> inconsitensies with the ASCII handling.
[...]
> My proposal, as done in the patch below, is to remove the
> special-casing of ASCII charachters altogether.  AFAIK, this is
> safe for current patforms, because we don't support non-ASCII
> platforms anyway.  

Is that actually true?  My understanding from Andrew Pinski is that the 
S/390 platform is a non-ASCII platform.  (I can't find any support for 
that claim in the documentation or mailing-list archives, however....)

> There is precedent; for example, ifort
> always uses the native character set for the ASCII functions.

Does IFort run on non-ASCII platforms, though?

Also, some implementation comments, if we go this route:
> @@ -271,17 +246,16 @@ gfc_expr *
>  gfc_simplify_achar (gfc_expr *e)
>  {
>    gfc_expr *result;
> -  int index;
> +  int c;
>  
>    if (e->expr_type != EXPR_CONSTANT)
>      return NULL;
>  
>    /* We cannot assume that the native character set is ASCII in this
>       function.  */

This comment needs to go, and be replaced by its inverse ("We assume 
that....")

> -  if (gfc_extract_int (e, &index) != NULL || index < 0 || index > 127)
> +  if (gfc_extract_int (e, &c) != NULL || c < 0 || c > UCHAR_MAX)
>      {
> -      gfc_error ("Extended ASCII not implemented: argument of ACHAR at %L "
> -		 "must be between 0 and 127", &e->where);
> +      gfc_error ("Bad character in ACHAR function at %L ", &e->where);
>        return &gfc_bad_expr;

This is still inconsistent, and still a standard violation.  ACHAR is 
valid for any integer input, and returns a processor-dependent value; 
thus, we should never return an error.  (Note that this is not the same 
as CHAR!)  The runtime just uses the bottom 8 bits of the input, I believe.

Personally, I think I'd prefer to have CHAR(0) returned for anything 
outside the 0-to-127 range, in both the constant-folding and runtime, 
but that's just me.

Also, regardless of the actual value returned, I do think that in the 
constant-folding we should have a warning for values outside 0-127, 
conditioned on -Wsurprising or something like that.  (And similarly for 
IACHAR on characters not in that range.)

- Brooks