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

Re: [PATCH] Fix error: array subscript has type 'char'

On 26.01.2021 18:59, Ian Jackson wrote:
> Manuel Bouyer writes ("Re: [PATCH] Fix error: array subscript has type 
> 'char'"):
>> On Thu, Jan 14, 2021 at 03:16:15PM +0100, Manuel Bouyer wrote:
>>> On Thu, Jan 14, 2021 at 02:25:05PM +0100, Jan Beulich wrote:
>>>> Which means you're shifting the undefined-ness from the implementation
> The undefined-ness is in the *specification*. [1]
>>>> Isn't this something that wants changing in your ctype.h instead?
>>>> the functions (or macros), as per the C standard
> Jan, can you please check your facts before asserting the existence
> of a pretty blatant bug in a platform's implementation of basic C
> functions ?
> From my copy of C99+TC1+TC2, para 7.4:
>  1   In all cases the argument is an int, the value of which shall be
>      representable as an unsigned char or shall equal the value of the
>      macro EOF.  If the argument has any other value, the behavior is
>      undefined. [...]
> If char is signed, then it can contain -ve values.  Those values are
> promoted to int by the usual integer promotions.  Naturally such
> negative values are not representable as unsigned char.  Passing them
> to ctype macros is UB.

I did read that part of the spec before replying. 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.

But yes, I'm not the maintainer of this code, so if you're
happy with such risks, so be it.

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.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.