Yo Greg! On Sun, 01 Nov 2026 07:54:46 -0500 Greg Troxel <[email protected]> wrote:
> So if a is of type "char", and on that platform/compiler char is
> signed (quite common), then if a holds for example é (value 233
> decimal, 0xe9), then when it is promoted to int, the results is -105.
> That is not "representable as an unsigned char" and it is not EOF.
> Therefore the behavior is undefined, and code that leads to UB is
> incorrect.
I had checked the musl, and other, source code and found not issues
with passing any int to isXXXXX(). But the GNU libc code does
in fact break:
/usr/include/ctype.h:
These point into arrays of 384, so they can be indexed by any
`unsigned char' value [0,255]; by EOF (-1); or by any `signed char'
value [-128,-1). ISO C requires that the ctype functions work for
`unsigned char' values and for EOF; we also support negative `signed
char' values for broken old programs.
So in their mind passing a signed char to isXXXX() is also bad, nut
tolerated. Ugh. The GNU libc man page should go beyond saying
"undefined" and mention OOB read.
That makes current gpsd code like this tolerated by GNU libc, but wrong:
./libgps/gpsutils.c: while (isspace((int)*p)) {
I'll do an audit of this. I wonder why coveriry never mantioned
this? Is there a gcc flag to error on this?
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
[email protected] Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgplqncOP2qka.pgp
Description: OpenPGP digital signature
