Patrick Welche writes:
> Since gcc9, essentially every ctype using piece of software fails with
>
>error: array subscript has type 'char' [-Werror=char-subscripts]
>
> which prompts a style question: cast every argument of every call to
> a ctype function in every piece of software to (unsigned char), or
> -Wno-error=char-subscripts], or something else?
There were earlier warnings that were similar. This is tricky business!
POSIX says (quoting C99, which is harder to give a URL to):
https://pubs.opengroup.org/onlinepubs/9699919799/functions/isalpha.html
which says that these are functions. However in NetBSD they are macros.
I have seen arguments that the macro implementation is legitimate. And,
I think a true function would have the same problem, just showing up
differently in terms of warnings (promoting char to int in a function
call, when the function has UB for many of those values -- a warning
less likely to be issued).
The caller must provide an int which is representable as unsigned char
(or EOF), says the definition, if you read it straightforwardly without
trying to be a language lawyer thinking about macros.
If you pass a char to a function that takes int, and char is a signed
type, and the value is negative, there is sign extension, and thus
undefined behavior when using a ctype function.
https://wiki.sei.cmu.edu/confluence/display/c/STR34-C.+Cast+characters+to+unsigned+char+before+converting+to+larger+integer+sizes
https://wiki.sei.cmu.edu/confluence/display/c/STR37-C.+Arguments+to+character-handling+functions+must+be+representable+as+an+unsigned+char
So, it's more than a style question; code that passes char to ctype
funtions is actually wrong, and yes it should all be fixed.
signature.asc
Description: PGP signature
