On Mon Jan 8, 2024 at 6:08 PM CST, Tom Lane wrote:
> "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.
Thanks for the explanation.
> > 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?
I'll leave it up to you. Patch looks good as-is.
--
Tristan Partin
Neon (https://neon.tech)
