4 ms·

Yes, some UB are not decidable at compile time, but a lot could be easily speced to have a defined behavior at runtime, such as overflows. The main reason to n

Yes, some UB are not decidable at compile time, but a lot could be easily speced to have a defined behavior at runtime, such as overflows. The main reason to not spec these things is because people would be arguing "this makes compiled code on my esoteric 9-bit 1-complement chip slower" or "there was this chip in the 70s that did things differently" or "but a short int on Cray was 64-bit". Great, so now the spec has avoidable unnecessary undefined behavior all over the place, and the code other people wrote still does not run correctly on your 9-bit chip. Brought to you by the same people who decided "NULL is not necessarily (void*)0", and who define those integer types everybody uses (instead of stdint) with an "at least this big". Yes, a lot of that is legacy stuff and was added to accommodate and model things that already existed (the wrong way to go about it, IMO, but hindsight is 20/20), but that's my argument: fix this stuff once and for all and for good in an upcoming spec iteration. >Without these assumptions the resulting compiled code would be much slower In some cases, this is true (for different levels of "much slower"), but the trade off here is still "running code that works, but a little slower" vs "running code that does not work and will launch a nuclear strike at Switzerland by accident, but really fast". In a lot of cases, it will not be slower, or at least not much slower. >I think your irritation is just based on a misunderstanding of the situation. Frankly, not really. I started writing my first C (and C++) in the early 90s, and I think I do understand the situation pretty well by now. But I should have been more precise in my initial ranting comment, I give you that. >They're not trying to screw anyone over. I didn't say that they are.

saagarjha 5y ago
Note that (void *)0 is always NULL, as mandated by the standard. But, to address the content of your comment: defined behavior at runtime is not necessarily good behavior at runtime. Defining signed integer overflow to wrap, for example, is probably a bad idea, because this is rarely the intent of the code. Having all such operations trap might be a good idea, but now you're going to get the same "stop breaking my working programs" people angry at you.
- rndgermandude 5y ago
  Yes, thankfully at least with NULL they didn't fall into the legacy trap and messed up the standard with non-zero NULL that some machines before have been kind of using. >Defining signed integer overflow to wrap, for example, is probably a bad idea I wouldn't call it great behavior, but it's at least what most people expect will happen, and most people will be able to understand what's going on, and it's fast on most systems that matter. However, it's still undefined behavior. Just codifying overflows to be wrapping, would therefore be an improvement in my opinion, at least over what we have today.
  - gpderetta 5y ago
    I would say that most people expect it not to happen. If they really had to mandate a behavior, it should be to trap.
- account42 5y ago
  > Note that (void *)0 is always NULL, as mandated by the standard. Also note that this is distinct from the memory representation of (void *)0 being all 0 bits, which is explicitly not mandated.

saagarjha 5y ago

Note that (void *)0 is always NULL, as mandated by the standard. But, to address the content of your comment: defined behavior at runtime is not necessarily good behavior at runtime. Defining signed integer overflow to wrap, for example, is probably a bad idea, because this is rarely the intent of the code. Having all such operations trap might be a good idea, but now you're going to get the same "stop breaking my working programs" people angry at you.

rndgermandude 5y ago
Yes, thankfully at least with NULL they didn't fall into the legacy trap and messed up the standard with non-zero NULL that some machines before have been kind of using. >Defining signed integer overflow to wrap, for example, is probably a bad idea I wouldn't call it great behavior, but it's at least what most people expect will happen, and most people will be able to understand what's going on, and it's fast on most systems that matter. However, it's still undefined behavior. Just codifying overflows to be wrapping, would therefore be an improvement in my opinion, at least over what we have today.
- gpderetta 5y ago
  I would say that most people expect it not to happen. If they really had to mandate a behavior, it should be to trap.
account42 5y ago
> Note that (void *)0 is always NULL, as mandated by the standard. Also note that this is distinct from the memory representation of (void *)0 being all 0 bits, which is explicitly not mandated.