"Tristan Partin" <tristan@neon.tech> writes:
> On Mon Jan 8, 2024 at 2:48 PM CST, Tom Lane wrote:
>> + (isascii((unsigned char) mybuf.data[mybuf.len - 1]) &&
>> + isspace((unsigned char) mybuf.data[mybuf.len - 1]))))
> Seems like if there was going to be any sort of casting, it would be to
> an int, which is what the man page says for these two function, though
> isascii(3) explicitly mentions "unsigned char."
Casting to unsigned char is our standard pattern for using these
functions. If "char" is signed (which is the only case in which
this changes anything) then casting to int would imply sign-extension
of the char's high-order bit, which is exactly what must not happen
in order to produce a legal value to be passed to these functions.
POSIX says:
The c argument is an int, the value of which the application shall
ensure is a character representable as an unsigned char or equal
to the value of the macro EOF. If the argument has any other
value, the behavior is undefined.
If we cast to unsigned char, then the subsequent implicit cast to int
will do zero-extension which is what we need.
> Small English nit-pick: I would drop the hyphen between semi and colons.
Me too, except that it's spelled like that in nearby comments.
Shall I change them all?
regards, tom lane
