And, given that behavior, that the documentation fails to explicitly call it out is borderline malicious. Given that the authors even knew about it, which I guess is doubtful.
As another example, notice that abs(number) has Undefined Behaviour for INT_MIN or whatever C calls it.
I don't consider abs() comparable. It is a direct consequence of underlying representation that you are kind of expected to know, the consequences are known and considered.
Is it bad? Depends on context.
isspace on the other hand, as described, just seems like bad design.
This is an extraordinary choice, made in the name of convenience, decades ago.
Wrapping here would match your claim that it's "a consequence of underlying representation". Saturating, rather odd here, but that too would be explicable. Runtime Error? Perhaps too heavyweight for a language like C but otherwise reasonable. But Undefined Behaviour is extraordinary.
There are tons of quirks in C, but abs() doesn't make the list in my book. It is just that the underlying representation (in the case of two-complement) doesn't allow for it to exist.
How does that matter? We're calling abs() which is not defined over the "two-complement system" it's defined on C's signed integer type, and the way it's defined is that if you call it with the valid integer INT_MIN you get Undefined Behaviour.
Let me underscore that, you don't necessarily get zero, or INT_MAX or five, or even INT_MIN (which might feel pretty unexpected given you just called abs and now you've got a negative number again - but is at least a defined behaviour) you get Undefined Behaviour. All bets are off.
The programmer who gets bitten by this isn't thinking about INT_MIN, they're thinking about how to check the input is in range, they've written abs(x) < 100 and they think this means they checked that x is between -99 and +99 inclusive, but they're wrong, what it did was introduce Undefined Behaviour into their program whenever x is INT_MIN.
Meanwhile, -2322 is a valid int on every C system but not an ASCII whitespace character on any of them. Therefore, it would be not only possible but perfectly reasonable for isspace() to return 0 for it. Classic violation of the principle of least surprise.
Because C is a low level language. It is not a mistake, it by design exposes hardware characteristics. If you don't care about that you probably shouldn't be using C.
I am the first to agree that undefined behavior in C is pretty bad. But this is trivially understood and one of the most basic examples. Can it still bite you in the ass? Sure.
I would prefer it to be implementation defined, but relying on that blindly isn't much better anyway.
It would be interesting to survey Rust programs here.
Rust's abs() on normal signed integer types function panics on overflow except in release builds (where it does the same as wrapping_abs)
Rust's wrapping_abs() gives MIN because that's what happens in two's complement arithmetic when you wrap around beyond MAX, this is probably undesirable for most people most of the time.
Rust's saturating_abs() gives MAX here, I would expect lots of programmers want that.
The Wrapping<T> and Saturating<T> types have abs() do what wrapping_abs() or saturating_abs() accordingly do on the basic integer type.
I didn't say that undefined behavior expose hardware characteristics, though I suppose for a lot of cases it really does - but the compiler won't assume so. I said that C exposes hardware characteristics. And C also has several architectures in mind.
Signed integer overflow is trivial on a two-complement system but not necessarily on others, so the lowest common denominator dictates what can be done. If the behavior is different or expensive you might shift that decision to the programmer.
Negating the sign of INT_MIN isn't cheap to do in a two-complement system.
Nonsense isn't a characteristic of the hardware. The hardware has very clearly defined behaviour, but C chooses not to expose that.
Anyway, doesn't seem like you are even trying to understand. No worries, I won't bother.
Just saying it needs to be able to fit an unsigned char and call it a day is hardly clear documentation when it isn't even obvious that the signness of the character type is implemention defined for most c-programers.
It almost reads as a deliberate trap (of course it isn't, but imo it is not good documentation).