Why the hell would you even report something as a bug when the code that causes the crash has undefined behavior? Why do you expect UB to work? Seriously… just… WHY?
Just because it's undefined behavior doesn't forbid you to think about what to do outside of the defined range. Especially if your competitors have done just that.
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.
bhaak|10 years ago
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.