3 ms·
If isspace is a function designed to take a character. And if the default type of a character is incompatible with the argument to that function then that is ar
by tjoff 5y ago
If isspace is a function designed to take a character. And if the default type of a character is incompatible with the argument to that function then that is arguably a bug in the specification.
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.
- hvdijk 5y agoThe documentation does call it out explicitly. The message you responded to pointed out where the documentation called it out. You're attacking the authors' intentions and competence when there is no reason for that.
- tjoff 5y agoThey do not explicitly call out that the systems default character is implementation specific and that the function as is might be incompatible with default behavior (on as it turns out the vast majority of systems). 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).
- tialaramex 5y agoThe C type system isn't really set up to deliver what you'd actually want for safety. The rational response is to not use C, but it took until relatively recently for people to really begin that migration. As another example, notice that abs(number) has Undefined Behaviour for INT_MIN or whatever C calls it.
- tjoff 5y agoIt is not, but then again a lot of people don't use a static type system at all. 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.
- tialaramex 5y agoNo, the consequences aren't "known and considered" as I explained, they are Undefined Behaviour. Absolutely anything might happen, anywhere in your program. 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.
- deleted 5y ago[deleted]
- tjoff 5y agoI meant the consequences of the two-complement system is known. 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.
- tialaramex 5y ago> I meant the consequences of the two-complement system is known. 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.
- tjoff 5y ago