OpenPrinting
[WIP] Clang-tidy fixes
All of these nonfunctional changes were suggested by clang-tidy, especially replacing new with malloc when necessary and doing the appropriate responses instead of just throwing an unhandled error.
@AtariDreams It looks like this PR has picked up the removal of "& 255" changes, which are part of another PR. I can't merge as-is...
Only calls to char functions that take an int were changed. Everything else was kept.
@AtariDreams The definition of the ctype macros allows for the value -1 (EOF constant) and character values from 0 to 255 (the range of a typical unsigned char with 8-bit bytes).
The char data type is (explicitly per the C standards going back to K&R) undefined WRT signedness. The default on some platforms is signed char, and others unsigned char. If char is unsigned, then the "& 255" is not needed. But if char is signed, these ctype macros blow up spectacularly when confronted with UTF-8 text.
Our options are:
- Keep the "& 255"
- Write new versions of the macros that explicitly ignore values outside the range of 0 to 127 (although that will have some side-effects for some 8-bit charsets that the ctype macros might otherwise support)
- Write new versions of the macros that are UTF-8 aware and take a pointer instead of an integer
We are a week away from the first beta of CUPS 2.4.0. I do not want to create huge code churn before a beta for something that is clearly necessary from a "don't write code that will crash at random times" POV, so the "& 255" (option 1) will stay for CUPS 2.4.x.
Longer term I favor option 3 since CUPS uses UTF-8 internally, only converting to/from UTF-8 as needed for the command-line tools. And if you want to tackle that challenge for 2.5.x, please do!
Putting this PR in the "2.5" milestone for now...
Hi @AtariDreams ,
have you had a time to look into changes which Mike'd requested?
I will put [WIP] into subject for now.
I have decided to split this change into multiple ones. Figured it would be for the best
@michaelrsweet I was wrong. You were right.
It turns out character literals are integers, not chars like in C++, so yeah the & 255 would make sense, even if we could remove them in practice and most likely get away with it since many of those functions do take integers anyway. I will revert them.