Re: [PATCH] Fix error: array subscript has type 'char' [and 1 more messages]

[Ian Jackson <iwj@xxxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [PATCH] Fix error: array subscript has type 'char'"):
> I did read that part of the spec before replying.

I find this quite astonishing.  You claimed that FreeBSD's libc was
buggy *after having read the spec to which you agree it conforms*.

>   Irrespective of the wording there it seems entirely unreasonable
> to me for the spec to imply all use sites of the is...() functions
> to have to use casts. Even more so that we all know (I suppose) that
> casts can be dangerous as both potentially introducing bugs (perhaps
> not at the point of their addition, but later when code elsewhere
> gets changed) and keeping analysis tools from actually spotting
> ones.

Nevertheless, this is the design of the C standard.  A common approach
to this problem is something like this (from libxl_internal.h):

  /*
   * int CTYPE(ISFOO, char c);
   * int CTYPE(toupper, char c);
   * int CTYPE(tolower, char c);
   *
   * This is necessary because passing a simple char to a ctype.h
   * is forbidden.  ctype.h macros take ints derived from _unsigned_ chars.
   *
   * If you have a char which might be EOF then you should already have
   * it in an int representing an unsigned char, and you can use the
   * <ctype.h> macros directly.  This generally happens only with values
   * from fgetc et al.
   *
   * For any value known to be a character (eg, anything that came from
   * a char[]), use CTYPE.
   */
  #define CTYPE(isfoo,c) (isfoo((unsigned char)(c)))

Jan Beulich writes ("Re: [PATCH] Fix error: array subscript has type 'char'"):
> On 27.01.2021 09:31, Jan Beulich wrote:
> > But yes, I'm not the maintainer of this code, so if you're
> > happy with such risks, so be it.
> 
> And actually I was only partly right here - there's one hunk
> here affecting code I'm the maintainer just as much as you
> are. At least there I'd like to ask that ...
> 
> > For the record, to me the less risky approach here would seem
> > to have been to make use of compilers allowing to choose
> > whether plain char is signed or unsigned, and force it to
> > unsigned for at least the affected components.
> 
> ... this be considered as an alternative, before I maybe
> withdraw my de-facto nak.

Whether char is signed or unsigned is generally specified in the
platform API/ABI.  Deviating from this for userland code is not
possible or reasonable since it would involve processing the system
headers with a deviant langauge definition!

Deviating from it for hypervisor code would be possible but I think it
would be unwise.

Ian.