[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. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |