5 ms·

This post has no point. Developers must avoid UB in their code, at all costs. Wondering what a specific compiler will do with your UB code is useless: as soon

by pif 2y ago

This post has no point. Developers must avoid UB in their code, at all costs. Wondering what a specific compiler will do with your UB code is useless: as soon as you realise you have UB, go and fix it!

cobbal 2y ago
Not pointless to a compiler writer. If a compiler is certain there's UB should it format the developer's hard drive immediately, or does it have to wait until the program is run before formatting to be standards compliant? On a more serious level, should it emit a warning? If it knows UB is reached, a warning sounds reasonable, but it's pretty rare that a compiler is 100% certain something is reached, and that analysis is probably not worth the cost.
- dgrunwald 2y ago
  > If a compiler is certain there's UB should it format the developer's hard drive immediately, or does it have to wait until the program is run before formatting to be standards compliant? The standard has enough variants of UB that both options are possible! For normal runtime UB (e.g. division by zero), it needs to wait until it is certain that the undefined code will actually be executed. So compilation/linking must not fail, the behavior is only undefined if the program is actually run. IFNDR (ill-formed, no diagnostic required) is a different kind of UB; here it is expected that compilation/linking may already fail. Then there's also the infamous "preprocessor UB" (e.g. https://wg21.link/p2621 https://wg21.link/p2621), which reuses the "undefined behavior" terminology despite not having anything to do with runtime semantics. I guess this is where the compiler might format your hard drive (old gcc versions actually launched nethack on undefined pragmas!).
unwind 2y ago
I would argue that one good point of the article is to illustrate to its readers just what it means, that compilers assume code to be free of undefined behavior. The resulting "reasoning" can be counter-intuitive, and seeing what happens and what problems it can introduce must be instructive to people who are not aware. Better informed/educated C programmers is an improvement on the state of the world, in my opinion.
- titzer 2y ago
  More knowledge is good. Hopefully it inspires people to avoid UB and demand better diagnostics and debugging tools for UB. Avoiding UB can include such activities as completely avoiding programming in the language that has UB. UB is a post-facto justification for compiler optimizations that only work on non-buggy programs. It's a circus because programs have bugs.
shadowgovt 2y ago
I don't think removing all UB is a tractable goal in most languages that are used and allow a lot of UB. In general, devs are choosing those languages because of some other feature that makes dancing on the rim of the cliff perpetually worth it. Given that reality, knowing what your compiler will do with UB is useful and important because you're going to see it all the time in debugging. Even if it's ugly, it needs to be treated as a familiar face.
- pif 2y ago
  > Given that reality, knowing what your compiler will do with UB ... The more you refuse to accept undefined behaviour, the more it will hurt when it will bite you! Stop turning around the problem and fix your code.
  - shadowgovt 2y ago
    I mean, I "fix my code" by avoiding languages with a lot of UB like the plague. I don't think writing a million lines of UB-free C++ is a human-shaped problem. We can pretend this is just a "skill issue," but even if it is it's a skill issue that's endemic to the industry (https://cwe.mitre.org/data/definitions/758.html https://cwe.mitre.org/data/definitions/758.html), so unless you're working on a project solo you're going to come across code that has UB and it's going to be your problem to fix it. Given that, plus the reality that we insist on continuing to write a million lines of C++, treating UB as something you'll see frequently in your career is probably the reality-based behavior.
    - pif 2y ago
      > treating UB as something you'll see frequently in your career Sure it is! I'm not talking about skills: everybody writes UB, at any time. I'm talking about attitude: when you see UB, you must strive to remove it, not to protect it!
      - shadowgovt 2y ago
        If that is your position, it makes sense. I didn't recognize it as your position because you presented "Developers must avoid UB in their code, at all costs" as supporting the preceding statement "This post has no point;" if your point is "developers should remove UB when they see it," then the point of this post is helping people see what UB looks like at the next layer of abstraction down as an aid to identifying and removing it. (The C++ standard is over 2,000 pages. It's impractical to believe developers see UB by reading the C++ source code; most is identified by an application behaving incorrectly followed by inspection of the machine code to understand where the developer's assumptions about the C++ specification failed to match with the actual specification).
pjc50 2y ago
This would be easier if things like "integer arithmetic" weren't undefined behavior.
kzrdude 2y ago
The post is very meaningful. You seem to care about developers avoiding UB. Exploring how compilers warn or don't warn for some of these cases is very meaningful - maybe it can lead to new warnings, or better tools so that developers can avoid UB.

by pif 2y ago

cobbal 2y ago

Not pointless to a compiler writer. If a compiler is certain there's UB should it format the developer's hard drive immediately, or does it have to wait until the program is run before formatting to be standards compliant? On a more serious level, should it emit a warning? If it knows UB is reached, a warning sounds reasonable, but it's pretty rare that a compiler is 100% certain something is reached, and that analysis is probably not worth the cost.

dgrunwald 2y ago
> If a compiler is certain there's UB should it format the developer's hard drive immediately, or does it have to wait until the program is run before formatting to be standards compliant? The standard has enough variants of UB that both options are possible! For normal runtime UB (e.g. division by zero), it needs to wait until it is certain that the undefined code will actually be executed. So compilation/linking must not fail, the behavior is only undefined if the program is actually run. IFNDR (ill-formed, no diagnostic required) is a different kind of UB; here it is expected that compilation/linking may already fail. Then there's also the infamous "preprocessor UB" (e.g. https://wg21.link/p2621 https://wg21.link/p2621), which reuses the "undefined behavior" terminology despite not having anything to do with runtime semantics. I guess this is where the compiler might format your hard drive (old gcc versions actually launched nethack on undefined pragmas!).

unwind 2y ago

I would argue that one good point of the article is to illustrate to its readers just what it means, that compilers assume code to be free of undefined behavior. The resulting "reasoning" can be counter-intuitive, and seeing what happens and what problems it can introduce must be instructive to people who are not aware. Better informed/educated C programmers is an improvement on the state of the world, in my opinion.

titzer 2y ago
More knowledge is good. Hopefully it inspires people to avoid UB and demand better diagnostics and debugging tools for UB. Avoiding UB can include such activities as completely avoiding programming in the language that has UB. UB is a post-facto justification for compiler optimizations that only work on non-buggy programs. It's a circus because programs have bugs.

shadowgovt 2y ago

I don't think removing all UB is a tractable goal in most languages that are used and allow a lot of UB. In general, devs are choosing those languages because of some other feature that makes dancing on the rim of the cliff perpetually worth it. Given that reality, knowing what your compiler will do with UB is useful and important because you're going to see it all the time in debugging. Even if it's ugly, it needs to be treated as a familiar face.

pif 2y ago
> Given that reality, knowing what your compiler will do with UB ... The more you refuse to accept undefined behaviour, the more it will hurt when it will bite you! Stop turning around the problem and fix your code.
- shadowgovt 2y ago
  I mean, I "fix my code" by avoiding languages with a lot of UB like the plague. I don't think writing a million lines of UB-free C++ is a human-shaped problem. We can pretend this is just a "skill issue," but even if it is it's a skill issue that's endemic to the industry (https://cwe.mitre.org/data/definitions/758.html https://cwe.mitre.org/data/definitions/758.html), so unless you're working on a project solo you're going to come across code that has UB and it's going to be your problem to fix it. Given that, plus the reality that we insist on continuing to write a million lines of C++, treating UB as something you'll see frequently in your career is probably the reality-based behavior.
  - pif 2y ago
    > treating UB as something you'll see frequently in your career Sure it is! I'm not talking about skills: everybody writes UB, at any time. I'm talking about attitude: when you see UB, you must strive to remove it, not to protect it!
    - shadowgovt 2y ago
      If that is your position, it makes sense. I didn't recognize it as your position because you presented "Developers must avoid UB in their code, at all costs" as supporting the preceding statement "This post has no point;" if your point is "developers should remove UB when they see it," then the point of this post is helping people see what UB looks like at the next layer of abstraction down as an aid to identifying and removing it. (The C++ standard is over 2,000 pages. It's impractical to believe developers see UB by reading the C++ source code; most is identified by an application behaving incorrectly followed by inspection of the machine code to understand where the developer's assumptions about the C++ specification failed to match with the actual specification).

pjc50 2y ago

This would be easier if things like "integer arithmetic" weren't undefined behavior.

kzrdude 2y ago

The post is very meaningful. You seem to care about developers avoiding UB. Exploring how compilers warn or don't warn for some of these cases is very meaningful - maybe it can lead to new warnings, or better tools so that developers can avoid UB.