"Tristan Partin" <tris...@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