Re: isspace() behaviour

[Patrick Welche <prlw1%welche.eu@localhost>]

On Wed, Dec 18, 2024 at 11:33:46AM +0100, Christoph Badura wrote:
> On Sun, Dec 15, 2024 at 08:34:35PM +0000, Patrick Welche wrote:
> > int main()
> > {
> >         printf("%d", isspace(0xffffffffu));
> > 
> >         return 0;
> > }
> > 
> > causes a segmentation fault on NetBSD-current/amd64, but returns 0 on
> > ubuntu 24. One could say "don't do that, 0xffffffffu isn't a valid char".
> 
> Is that actual usage in the code or something whipped up to demonstrate
> the issue?

That is something whipped up to demonstrate what happens in the code.
A "minimal reproducer" if you will...


> > (That value was used in the program as "an EOF occured when that char
> > was read".)
> 
> "an EOF occured when that char was read" leaves me stumped.
> Clearly, if you are able to read a char, you weren't at EOF and if you
> were at EOF you wouldn't be able to read a char.  That's how Unix has
> worked forever.

The code is defining its own

#define ENDFILE            0xffffffffu       /* Too large to be a character */

and using it instead of EOF (why bother?).

Using EOF instead would be fine, as it is an int and not an unsigned int, viz

isspace(0xffffffffu) and isspace(0xffffffff) give a segmentation fault
isspace((int)0xffffffff) and isspace(EOF) don't.

A small hurdle was "but it works on linux" hence the email to this list,
and John Kollasch pointed to the CAVEATS section of ctype(3) within
minutes - thanks!


Cheers,

Patrick