5 ms·

> which is of course not a world that co-exists with our own The "our own" world you are describing has recently been created by UB-exploiting compilers; it's

by gpvos 5y ago

> which is of course not a world that co-exists with our own The "our own" world you are describing has recently been created by UB-exploiting compilers; it's a very strange and unintuitive place, is only described in inscrutable standards documents, and compilers don't properly warn you if you do something wrong even if you ask them to. A bit more understanding of people making mistakes seems appropriate.

mpweiher 5y ago
And in fact, most of "us" don't inhabit this world voluntarily. And the standards in question are actually have very clear and simple language disallowing those shenanigans. "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)." Alas, that language was made non-binding and now the people who made it non-binding pretend it doesn't exist at all. https://blog.metaobject.com/2018/07/a-one-word-change-to-c-standard-to-make.html https://blog.metaobject.com/2018/07/a-one-word-change-to-c-s...
- ChrisSD 5y ago
  Hm, I think "ignoring the situation completely with unpredictable results" pretty much covers everything. It's how optimizations generally work. Each optimization pass simply assumes there's no UB in the input and will optimize based on that assumption. Optimizing compilers don't intentionally break programs with UB, they just ignore the possibility... with very unpredictable results.
  - mpweiher 5y ago
    I don't think "optimising based on UB" is covered by "ignoring". And neither is "optimising assuming UB never happens", especially if said UB is explicitly written in the code, thus contradicting the assumption.
    - ChrisSD 5y ago
      The compiler doesn't know if the program contains UB or not. How could it? Sure it can have warnings for some well know UB patterns but it can't catch them all. There are dedicated tools designed to detect UB which are not only very slow but fail to be totally effective (they have both false positive and negatives). So the compiler simply ignores this possibility and optimizes assuming the input is a valid C program.
      - mpweiher 5y ago
        This isn't remotely true. Unless you use the sleight of hand that is commonly used in vastly expanding the meaning of the word "valid" to mean "the compiler can assume there is no UB". Which, again, isn't "ignoring the situation".
        SAI_Peregrinus 5y ago
        I disagree that it isn't "ignoring the situation". By analogy, if you saw a purple streetlight would you keep driving, stop, turn left, turn right, or make a U turn? You have to do something! You'd probably assume it's a prank, and treat it as a green light by proceeding normally. Compiler code gen around UB is no more complex than this, though the consequences can cause complex chains of reasoning in later optimization passes.
        mpweiher 5y ago
        Hard disagree, your analogy is (still) incorrectly equating UB with "this should never happen". That's not what UB is. UB is "the standard doesn't say anything about this particular situation, because we intentionally left the standard incomplete". It never said "UB cannot happen". But even assuming your "purple streetlight" analogy, it exactly does not cover the "complex chains of reasoning" that the compilers then do. I saw a purple streetlight, therefore I can just assume it is green. Nope. I saw a purple streetlight, therefore I can now run over pedestrians. Nope. I saw a purple streetlight, therefore this now an airport runway. Nope. The compiler-writers' justifications don't pass even the most minimal test for coherence.

by gpvos 5y ago

mpweiher 5y ago

And in fact, most of "us" don't inhabit this world voluntarily. And the standards in question are actually have very clear and simple language disallowing those shenanigans. "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)." Alas, that language was made non-binding and now the people who made it non-binding pretend it doesn't exist at all. https://blog.metaobject.com/2018/07/a-one-word-change-to-c-standard-to-make.html https://blog.metaobject.com/2018/07/a-one-word-change-to-c-s...

ChrisSD 5y ago
Hm, I think "ignoring the situation completely with unpredictable results" pretty much covers everything. It's how optimizations generally work. Each optimization pass simply assumes there's no UB in the input and will optimize based on that assumption. Optimizing compilers don't intentionally break programs with UB, they just ignore the possibility... with very unpredictable results.
- mpweiher 5y ago
  I don't think "optimising based on UB" is covered by "ignoring". And neither is "optimising assuming UB never happens", especially if said UB is explicitly written in the code, thus contradicting the assumption.
  - ChrisSD 5y ago
    The compiler doesn't know if the program contains UB or not. How could it? Sure it can have warnings for some well know UB patterns but it can't catch them all. There are dedicated tools designed to detect UB which are not only very slow but fail to be totally effective (they have both false positive and negatives). So the compiler simply ignores this possibility and optimizes assuming the input is a valid C program.
    - mpweiher 5y ago
      This isn't remotely true. Unless you use the sleight of hand that is commonly used in vastly expanding the meaning of the word "valid" to mean "the compiler can assume there is no UB". Which, again, isn't "ignoring the situation".
      - SAI_Peregrinus 5y ago
        I disagree that it isn't "ignoring the situation". By analogy, if you saw a purple streetlight would you keep driving, stop, turn left, turn right, or make a U turn? You have to do something! You'd probably assume it's a prank, and treat it as a green light by proceeding normally. Compiler code gen around UB is no more complex than this, though the consequences can cause complex chains of reasoning in later optimization passes.
        mpweiher 5y ago
        Hard disagree, your analogy is (still) incorrectly equating UB with "this should never happen". That's not what UB is. UB is "the standard doesn't say anything about this particular situation, because we intentionally left the standard incomplete". It never said "UB cannot happen". But even assuming your "purple streetlight" analogy, it exactly does not cover the "complex chains of reasoning" that the compilers then do. I saw a purple streetlight, therefore I can just assume it is green. Nope. I saw a purple streetlight, therefore I can now run over pedestrians. Nope. I saw a purple streetlight, therefore this now an airport runway. Nope. The compiler-writers' justifications don't pass even the most minimal test for coherence.