3 ms·

> If the compiler "ignores the situation" with UB, code path 1 is ignored (i.e., dropped from consideration). This probably results in the removal of the snippe

> If the compiler "ignores the situation" with UB, code path 1 is ignored (i.e., dropped from consideration). This probably results in the removal of the snippet as dead code. Ignoring something != killing something. There is no dialect of English in which ignoring something is compatible with eliminating it from existence. EDIT: Note: I am not personally saying compiler writers are wrong. The body text says it imposes no requirements, so at the very least it's a reasonable interpretation to say the footnote text isn't binding and/or that "possible" behaviors are examples, not a full enumeration. But! On the narrow question of "ignoring" the behavior altogether... Hunting for UB via static analysis and then changing your output based on whether you find it simply is not what the word "ignoring" means.

gpderetta 4y ago
The compiler is not removing or killing invalid code, you can still find it in the source file. What is doing, in the extreme case, is ignoring it and not generating asm statements for it. Then again, how it could? Code that will trigger UB has no meaning so the compiler wouldn't know what code to generate. Of course a compiler could assign meaning to some instance to UB. For example I'm pretty sure that in GCC dereferencing a null pointer is not UB, but it is expected to trap (because POSIX) and the execution not to continue except via abnormal edges (exceptions or longjmp). This means that any code that can be proven to be reachable only through a nullpter dereference is effectively dead code, so in practice it can still introduce bugs if it didn't trap.
aw1621107 4y ago
At least as far as one is unable to distinguish between the two, sure it is. A compiler that emits code as if UB-containing code paths are not there is essentially performing the dictionary definition of ignoring something, but it's functionally indistinguishable from a compiler that deletes UB-containing code paths.
- mpweiher 4y ago
  No. What you are describing is ignoring the code that has the undefined behaviour due to it having undefined behaviour. That is not ignoring the undefined behaviour, it is the opposite.
  - aw1621107 4y ago
    Maybe it's not "ignoring the undefined behaviour", but why isn't it ignoring the situation? The situation is that this code (path) invokes UB. Ignoring "the situation" seems to allow simply not considering that path. Maybe that results in that path not being emitted. Again, it all comes down to interpreting "the situation". Compiler writers construe it broadly; "Ignore the presence of UB" (i.e., construing "the situation" narrowly) is another possible interpretation, but I don't think it's the one and only definitive one. In addition, why isn't "ignore the presence of UB" covered by "behaving during translation or program execution in a documented manner characteristic of the environment"? See a null pointer dereference? Just do the "characteristic thing" during translation and emit the dereference. Maybe implementations will need to add documentation somewhere, but that's not exactly the challenging part.
    - mpweiher 4y ago
      Because it is not ignoring the undefined behaviour. Simple as that. What you are confusing is "being agnostic about something happening or not happening" and "assuming it cannot happen". And sorry, the "situation" is pretty precisely scoped by "Permissible undefined behavior...". So what can be ignored is this instance of UB, not the fact that UB exists. Otherwise, if you're going to arbitrarily expand the scope of what the situation is, then how about "the fact that a C spec exist?". That's a situation, after all, and it is the situation you are in. Or maybe just ignore parts of the spec, like the ones that define what is UB and what is not UB. Then everything becomes a trigger, and if I can expand scope like that, then I have a standards-compliant C-compiler for you: int main() { int a = *-1; } (I am pretty sure you can make a smaller one) I doubt anyone would accept this broadening of the scope. Once again, ignoring something is not generally the same as assuming it doesn't exist. They could be the same if you assume it doesn't exist and then do nothing differently. However, if you use your assumption that it doesn't exist and act differently based on that assumption than if it did exist, then you are not ignoring the situation. And the latter is clearly what is happening with today's optimising C compilers. They act very differently in the presence of UB than they would if the UB would not be there, for example not translating code that they would have translated had the UB not been there, had it not been UB or had they actually ignored the UB as the should have. > just do the "characteristic thing" during translation and emit the [null pointer] dereference These things overlap slightly, but I doubt that "just emitting the dereference" qualifies as a documented exception to normal processing of a pointer dereference due to UB. It is exactly the same thing it does when the pointer dereference is UB, so it is just ignoring the UB. Another misinterpretation that seems to be common is to interpret "the environment" in "characteristic of the environment" to include the (optimising) compiler itself.
aw1621107 4y ago
To respond to your edit: > Hunting for UB via static analysis and then changing your output based on whether you find it simply is not what the word "ignoring" means. Why not? A static analysis pass can flag a code path as containing UB, and future passes can then ignore that path. Sure sounds like "ignoring" to me.
- torstenvl 4y ago
  Ignoring Y because it has X is the opposite of ignoring X. It is fundamentally impossible to both ignore X and make decisions based on X at the same time. Something cannot be both ignored and a key criterion. Your argument is akin to saying that a company hiring process that "ignores race" means eliminating applicants based on their race. It is untrue. It is the opposite of true. And I think you know that, so please stop trolling.
  - deleted 4y ago
    [deleted]
  - aw1621107 4y ago
    > It is fundamentally impossible to both ignore X and make decisions based on X at the same time. Of course you can - the former can be the action you take as a result of the decision. Choosing to not consider something is distinct from refusing to make a decision based on that something, but both are "ignoring" that something. Again, this boils down to how "ignoring the situation" is interpreted. I can ignore situations with UB and proceed as if those situations aren't present, or I can ignore situations with UB and proceed as if the UB weren't present. The Standard's wording does not rule out one or the other. In addition, why would the "ignore the existence of UB" not fall under "behaving during translation or program execution in a documented manner characteristic of the environment"? That seems to match "pretend the UB were not present" much more closely. > Your argument is akin to saying that a company hiring process that "ignores race" means eliminating applicants based on their race. No, it means that the hiring process makes decisions without considering what race-based effects that may have. If that happens to result in weird race-based outcomes, then that's what happens.

gpderetta 4y ago

The compiler is not removing or killing invalid code, you can still find it in the source file. What is doing, in the extreme case, is ignoring it and not generating asm statements for it. Then again, how it could? Code that will trigger UB has no meaning so the compiler wouldn't know what code to generate. Of course a compiler could assign meaning to some instance to UB. For example I'm pretty sure that in GCC dereferencing a null pointer is not UB, but it is expected to trap (because POSIX) and the execution not to continue except via abnormal edges (exceptions or longjmp). This means that any code that can be proven to be reachable only through a nullpter dereference is effectively dead code, so in practice it can still introduce bugs if it didn't trap.

aw1621107 4y ago

At least as far as one is unable to distinguish between the two, sure it is. A compiler that emits code as if UB-containing code paths are not there is essentially performing the dictionary definition of ignoring something, but it's functionally indistinguishable from a compiler that deletes UB-containing code paths.

mpweiher 4y ago
No. What you are describing is ignoring the code that has the undefined behaviour due to it having undefined behaviour. That is not ignoring the undefined behaviour, it is the opposite.
- aw1621107 4y ago
  Maybe it's not "ignoring the undefined behaviour", but why isn't it ignoring the situation? The situation is that this code (path) invokes UB. Ignoring "the situation" seems to allow simply not considering that path. Maybe that results in that path not being emitted. Again, it all comes down to interpreting "the situation". Compiler writers construe it broadly; "Ignore the presence of UB" (i.e., construing "the situation" narrowly) is another possible interpretation, but I don't think it's the one and only definitive one. In addition, why isn't "ignore the presence of UB" covered by "behaving during translation or program execution in a documented manner characteristic of the environment"? See a null pointer dereference? Just do the "characteristic thing" during translation and emit the dereference. Maybe implementations will need to add documentation somewhere, but that's not exactly the challenging part.
  - mpweiher 4y ago
    Because it is not ignoring the undefined behaviour. Simple as that. What you are confusing is "being agnostic about something happening or not happening" and "assuming it cannot happen". And sorry, the "situation" is pretty precisely scoped by "Permissible undefined behavior...". So what can be ignored is this instance of UB, not the fact that UB exists. Otherwise, if you're going to arbitrarily expand the scope of what the situation is, then how about "the fact that a C spec exist?". That's a situation, after all, and it is the situation you are in. Or maybe just ignore parts of the spec, like the ones that define what is UB and what is not UB. Then everything becomes a trigger, and if I can expand scope like that, then I have a standards-compliant C-compiler for you: int main() { int a = *-1; } (I am pretty sure you can make a smaller one) I doubt anyone would accept this broadening of the scope. Once again, ignoring something is not generally the same as assuming it doesn't exist. They could be the same if you assume it doesn't exist and then do nothing differently. However, if you use your assumption that it doesn't exist and act differently based on that assumption than if it did exist, then you are not ignoring the situation. And the latter is clearly what is happening with today's optimising C compilers. They act very differently in the presence of UB than they would if the UB would not be there, for example not translating code that they would have translated had the UB not been there, had it not been UB or had they actually ignored the UB as the should have. > just do the "characteristic thing" during translation and emit the [null pointer] dereference These things overlap slightly, but I doubt that "just emitting the dereference" qualifies as a documented exception to normal processing of a pointer dereference due to UB. It is exactly the same thing it does when the pointer dereference is UB, so it is just ignoring the UB. Another misinterpretation that seems to be common is to interpret "the environment" in "characteristic of the environment" to include the (optimising) compiler itself.

aw1621107 4y ago

To respond to your edit: > Hunting for UB via static analysis and then changing your output based on whether you find it simply is not what the word "ignoring" means. Why not? A static analysis pass can flag a code path as containing UB, and future passes can then ignore that path. Sure sounds like "ignoring" to me.

torstenvl 4y ago
Ignoring Y because it has X is the opposite of ignoring X. It is fundamentally impossible to both ignore X and make decisions based on X at the same time. Something cannot be both ignored and a key criterion. Your argument is akin to saying that a company hiring process that "ignores race" means eliminating applicants based on their race. It is untrue. It is the opposite of true. And I think you know that, so please stop trolling.
- deleted 4y ago
  [deleted]
- aw1621107 4y ago
  > It is fundamentally impossible to both ignore X and make decisions based on X at the same time. Of course you can - the former can be the action you take as a result of the decision. Choosing to not consider something is distinct from refusing to make a decision based on that something, but both are "ignoring" that something. Again, this boils down to how "ignoring the situation" is interpreted. I can ignore situations with UB and proceed as if those situations aren't present, or I can ignore situations with UB and proceed as if the UB weren't present. The Standard's wording does not rule out one or the other. In addition, why would the "ignore the existence of UB" not fall under "behaving during translation or program execution in a documented manner characteristic of the environment"? That seems to match "pretend the UB were not present" much more closely. > Your argument is akin to saying that a company hiring process that "ignores race" means eliminating applicants based on their race. No, it means that the hiring process makes decisions without considering what race-based effects that may have. If that happens to result in weird race-based outcomes, then that's what happens.