5 ms·
He doesn't really address any of the claims made, and makes some startling claims himself. For example: > This example demonstrates that even ICC with -O1 alr
by mpweiher 5y ago
He doesn't really address any of the claims made, and makes some startling claims himself. For example:
> This example demonstrates that even ICC with -O1 already requires unrestricted UB.
The example demonstrates nothing of the sort. It demonstrates that ICC uses unrestricted undefined behaviour, not that this is required in any way shape or form. (The only way the word "requires" is reasonable here is that the behavior seen "requires" use of this kind of UB to be present. But that's something very different, and doesn't match with the rest of his use).
> writing C has become incredibly hard since undefined behavior is so difficult to avoid
No, it has become difficult because compilers exploit UB in insane ways. The platform specific UB that he claims is "not an option" is, incidentally, exactly how UB is defined in the standard:
Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
This was made non-binding in later versions of the standard, so optimiser engineers act as if these words don't exist.
And of course there is no reason given for this interpretation being "not an option". Except for "but I wanna". Yes, it's not an option if you really want to exploit UB in the insane ways that compilers these days want to exploit it.
But that's not necessary in any way shape or form.
> That would declare all but the most basic C compilers as non-compliant.
Yes, because by any sane interpretation of the standard they are non-compliant.
On a more general note, I find this idea that things are necessary because I want to do them really bizarre.
- gpderetta 5y agosorry, I don't understand, it seems to me that current optimizing compilers are fully compliant with the option of "ignoring the situation completely with unpredictable results". That's how UB exploiting optimizations work: the compiler ignores the possibility that the erroneous case can ever happen and takes into account only all valid states.
- mpweiher 5y agoApologies, but "ignoring the situation completely with undpredictable results" is the exact opposite of "assuming the situation cannot occur and acting on that assumption". If my program attempts to write outside the bounds of declared array, ignoring the situation (that this is UB) is letting that write happen, and letting the chips fall where they might. How is assuming it cannot/must not happen, and then optimising it away because it did happen "ignoring the situation"??
- gpderetta 5y agoSo a compiler that is allowed to ignore a situation would still be required to generate code for that situation? I don't even know how that would be possible.
- mpweiher 5y agoIt ignores the fact that this is UB. It is not just "possible", but exceedingly simple to comply with what is written in the standard and generate code in that situation. For example: Writing beyond the bounds of an array whose length is known is apparently UB. int a[4]; a[2]=2; a[6]=10; To generate code for the last line, use the same algorithm you used to generate code for the second line, just parameterised with 6 instead of 2. What was impossible about that?
- gpderetta 5y agoIf each of a[0...3] is stored only inside registers, which register should the compiler pick for a[6]?
- mpweiher 5y agoWho is forcing the compiler to store fracking arrays in registers? Once again, “incompatible with weird optimizations I want to do” is not close to the same thing as “not possible”. If the two are incompatible, it is obviously the weird optimization that has to go. How do you pass the address of that array to another function?
- aw1621107 5y ago> This was made non-binding in later versions of the standard, so optimiser engineers act as if these words don't exist. This is reminiscent of the argument in "How One Word Broke C" [0, HN discussion at 1]. I'm not particularly convinced this argument is correct. In my opinion, it's "ignoring the situation completely" that's the phrase of interest; after all, what is assuming that UB cannot occur but "ignoring the situation completely"? I'm a nobody, though, so take that with an appropriate grain of salt. [0]: https://news.quelsolaar.com/2020/03/16/how-one-word-broke-c/ https://news.quelsolaar.com/2020/03/16/how-one-word-broke-c/ (currently broken; archive at https://web.archive.org/web/20210307213745/https://news.quelsolaar.com/2020/03/16/how-one-word-broke-c/ https://web.archive.org/web/20210307213745/https://news.quel... [1]: https://news.ycombinator.com/item?id=22589657 https://news.ycombinator.com/item?id=22589657
- mpweiher 5y agoApologies, but "ignoring the situation completely" is the exact opposite of "assuming the situation cannot occur and acting on that assumption".
- aw1621107 5y agoI'm not sure how "acting on an assumption that the situation cannot occur" is distinguishable from "choosing to ignore situations completely whenever they come up". The former is a blanket description of how you treat individual instances. For example: int f(int* i) { int val = *i; if (i == NULL) { return 0; } return val; } I submit that there are two situations here: 1. i is NULL. Program flow will be caught by the NULL check and the return value is 0. 2. i is not NULL. The NULL check cannot be hit, and the return value is val. As allowed by the standard, I'll just ignore the situation with UB, leaving > i is not NULL. The NULL check cannot be hit, and the return value is val. Alternatively, I can assume that UB cannot occur, which eliminates option 1, leaving > i is not NULL. The NULL check cannot be hit, and the return value is val. You get the same result either way. And that gets to the root of the problem: What exactly does "ignoring the situation completely" mean? In particular, what is the scope of a "situation"?