[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] Fix error: array subscript has type 'char' [and 1 more messages]
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.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |