Patrick Welche <prlw1%cam.ac.uk@localhost> 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.
Attachment:
signature.asc
Description: PGP signature