4 ms·

I think that reasoning about things is a good idea and looking at failure modes is an engineers job. However, I gather that the standard says "undefined", so a

I think that reasoning about things is a good idea and looking at failure modes is an engineers job. However, I gather that the standard says "undefined", so a correct answer to what "happens with this code" might be: "wankery" (on the part of the questioner). You even demonstrate that undefined status with concrete examples. In another discipline you might ask what happens what happens when you stress a material near to or beyond its plastic limit? It's quite hard to find that limit precisely, without imposing lots of constraints. For example take a small metal thing eg a paper clip and bend it repeatedly. Eventually it will snap due to quite a few effects - work hardening, plastic limit and all that stuff. Your body heat will affect it, along with ambient temperature. That's before we worry about the material itself which a paper clip will be pretty straightforwards ... ish! OK, let's take a deeper look at that crystalline metallic structure ... or let's see what happens with concrete or concrete with steel in it, ooh let's stress that stuff and bend it in strange ways. Anyway, my point is: if you have something as simple as a standard that says: "this will go weird if you do it" then accept that fact and move on - don't try to be clever.

immibis 2y ago
"undefined" means "defined elsewhere".
- david-gpu 2y ago
  LOL. No. Some languages/libraries even make an explicit distinction between Undefined and Implementation-Defined, where only the latter is documented on a vendor-by-vendor basis. Undefined Behavior will typically vary across vendors and even within versions or whatnot within the same vendor. The very engineers who implemented the code may be unaware of what may happen when different types of UB are triggered, because it is likely not even tested for.
  - immibis 2y ago
    So it's defined in the compiler's source code. God doesn't roll a die every time you dereference null. Demons flying out of your nose would conform to the C++ standard, but I assure you that it would violate other things, such as the warranty on your computer that says it does not contain nasal demons, and your CPU's ISA, which does not contain a "vmovdq nose, demons" instruction.
    - david-gpu 2y ago
      No. The compiler isn't the only component of the system that will determine what happens when you trigger UB, either. There is UB all the way down to hardware specifications. I used to be one of the folks who defined the behavior of both languages and hardware at various companies. UB does not mean "documented elsewhere". Please stop spreading misinformation.
      - gerdesj 2y ago
        "I used to be one of the folks who defined the behavior of both languages and hardware at various companies" But not at all companies, orgs or even in Heaven and certainly (?) not at ISO/OSI/LOL. It appears that someone wants to redefine the word "undefined" - are they sure that is wise?
      - motorest 2y ago
        > No. The compiler isn't the only component of the system that will determine what happens when you trigger UB, either. There is UB all the way down to hardware specifications. I don't think you know what undefined behavior is. That's a concept relevant to language specifications alone. It does not trickle up or down what language specifications cover. It just means that the authors of the specification intentionally left the behavior expected from a specific scenario as undefined. For those who write software targeting language specifications this means they are introducing a bug because they are presuming their software will show a behavior which is not required by the standard. For those targeting specific combinations of compiler and hardware, they need to do their homework to determine if the behavior is guaranteed.
        immibis 2y ago
        Hardware also has UB, but what happens is still dictated by the circuitry. The relevant circuitry is both complicated enough and not useful enough for the CPU designer to specify it. Often they use the word "unpredictable" instead. The behavior is perfectly predictable by an omniscient silicon demon, but you may not be able to predict it. The effect that speculative execution has on cache state turned out to be unpredictable, so we have all the different Spectre vulnerabilities. Hardware unpredictability doesn't overlap much with language UB, anyway. It's unlikely that something not defined by the language is also not defined by th hardware. It's much more likely that the compiler's source code fully defines the behaviour.
  - motorest 2y ago
    [flagged]

immibis 2y ago

"undefined" means "defined elsewhere".

david-gpu 2y ago
LOL. No. Some languages/libraries even make an explicit distinction between Undefined and Implementation-Defined, where only the latter is documented on a vendor-by-vendor basis. Undefined Behavior will typically vary across vendors and even within versions or whatnot within the same vendor. The very engineers who implemented the code may be unaware of what may happen when different types of UB are triggered, because it is likely not even tested for.
- immibis 2y ago
  So it's defined in the compiler's source code. God doesn't roll a die every time you dereference null. Demons flying out of your nose would conform to the C++ standard, but I assure you that it would violate other things, such as the warranty on your computer that says it does not contain nasal demons, and your CPU's ISA, which does not contain a "vmovdq nose, demons" instruction.
  - david-gpu 2y ago
    No. The compiler isn't the only component of the system that will determine what happens when you trigger UB, either. There is UB all the way down to hardware specifications. I used to be one of the folks who defined the behavior of both languages and hardware at various companies. UB does not mean "documented elsewhere". Please stop spreading misinformation.
    - gerdesj 2y ago
      "I used to be one of the folks who defined the behavior of both languages and hardware at various companies" But not at all companies, orgs or even in Heaven and certainly (?) not at ISO/OSI/LOL. It appears that someone wants to redefine the word "undefined" - are they sure that is wise?
    - motorest 2y ago
      > No. The compiler isn't the only component of the system that will determine what happens when you trigger UB, either. There is UB all the way down to hardware specifications. I don't think you know what undefined behavior is. That's a concept relevant to language specifications alone. It does not trickle up or down what language specifications cover. It just means that the authors of the specification intentionally left the behavior expected from a specific scenario as undefined. For those who write software targeting language specifications this means they are introducing a bug because they are presuming their software will show a behavior which is not required by the standard. For those targeting specific combinations of compiler and hardware, they need to do their homework to determine if the behavior is guaranteed.
      - immibis 2y ago
        Hardware also has UB, but what happens is still dictated by the circuitry. The relevant circuitry is both complicated enough and not useful enough for the CPU designer to specify it. Often they use the word "unpredictable" instead. The behavior is perfectly predictable by an omniscient silicon demon, but you may not be able to predict it. The effect that speculative execution has on cache state turned out to be unpredictable, so we have all the different Spectre vulnerabilities. Hardware unpredictability doesn't overlap much with language UB, anyway. It's unlikely that something not defined by the language is also not defined by th hardware. It's much more likely that the compiler's source code fully defines the behaviour.
- motorest 2y ago
  [flagged]