Fuzzing with american fuzzy lop

My guess to why they did it this way was that it was an optimization and/or possible support for different locales.

Even though it's undefined behavior, considering that other libc implementations don't have this issue, making a simple function like isblank so complicated that it may crash, makes you wonder what other abominations lurk in that code.

I'd considered a table-driven approach - I mean, perhaps it's a bit daft for isblank, but OK for some of the more random categories - but assumed they'd index on c&0xFF or something, rather than just using the int input verbatim!

It's not immediately obvious to me why that wasn't done (maybe glibc has to support one's complement?), since none of the high-bit ASCII chars appear to have a defined value. Then you can decide EOF is -1 - no reason not to - and it would capture that as well. (The functions don't appear to have a defined output for EOF, even though it's a defined input, so it could just shared the same output as (signed char)-1, and that would be OK. At least it's not a crash.)

Technically, this issue is already covered by saying "The behavior is undefined if the value of ch is not representable as unsigned char and is not equal to EOF."

But in reality it is of course hilarious if a simple function like isblank() can crash if though it only check (in the default locale) if its parameter is equal to 9 or 32.

I also checked other libc implementations (IIRC the BSD, OSX, dietlibc and Bionic) and none of the others did crash or even produce surprising results with values outside of the defined range.

In this case, we even have a notorious range. EOF (which usually is implemented as -1) and unsigned char. You can't easily represent that in standard C types without using a type that lets most of the type's range fall into the range of undefined behavior.

I didn't expect undefined behavior to work, I didn't know that it was undefined behavior as the parameter you have to pass is an int. So the compiler can't inform me that I'm doing it wrong and at runtime, there are no checks. So, this bug in the code can go unnoticed for a long time.

BTW, note that isascii() is defined on all int values. It's all POSIX, so there is probably a historical reason for that. But the defined range of isascii() proves that covering the whole range of the input parameter's type is not something outrageous to ask for.