freemint / mintlib

libc variant for TOS and FreeMiNT OS
GNU General Public License v2.0
22 stars 10 forks source link

iscntrl() broken? #56

Open th-otto opened 1 year ago

th-otto commented 1 year ago

I ever wondered about the strange extra code for iscntrl() in ctype.h. I explicitly returns 0 for EOF(-1), and 1 for 255.

But i think that is wrong. In all environments where i tested it, only characters 0-31 and 127 return != for iscntrl, and in all cases both -1 and 255 return 0.

And there is also room for optimizations. Even if we want to keep the current behaviour, we do not need to explicitly check the 255 case. The same effect can be achieved by setting myctype[255] to zero. It would also by possible to get rid of the extra access through the _ctype pointer, and to make the array(s) unsigned char instead of int in order to save some space, essentially implementing it similar to libcmini.

Any suggestions?

mikrosk commented 1 year ago

The specification would suggest that you are correct: https://en.cppreference.com/w/cpp/string/byte/iscntrl

xdelatour commented 1 year ago

I agree that only 0-31 and 127 are control characters: https://cplusplus.com/reference/cctype/iscntrl/, https://www.oreilly.com/library/view/c-in-a/0596006977/re117.html and https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/iscntrl-iswcntrl-iscntrl-l-iswcntrl-l?view=msvc-170

musl-libc uses:

return (unsigned)c < 0x20 || c == 0x7f;

Unfortunately the old thread (February and March 2000) on the mailing list doesn't help