4 ms·

> didn't have a spec to follow or disobey anyways. Exactly. Yet they were still C compilers. So the idea that "being a C compiler" is the same as "follows t

> didn't have a spec to follow or disobey anyways. Exactly. Yet they were still C compilers. So the idea that "being a C compiler" is the same as "follows the spec" is clearly nonsense. You can follow the spec and not be a usable C compiler, and you can be a usable C compiler and not follow the spec. And the C spec not being complete was intentional, because otherwise too many already existing C compiler would have not had a chance of becoming ANSI compliant, and thus the spec would have been meaningless. > They clearly stated the opposite: > [..] > Permissible undefined behavior ranges from ignoring ... Very clearly gives a list of "permissible behaviors". Now if you believe that one of those options is "do anything you please" when it both clearly doesn't say that, it just "ignore with unpredictable results" AND it doesn't make logical sense, not sure how to help you. (The two other options for permissible behavior are clearly completely redundant if one of them permits you to do anything you want whatsoever). > "next time we see an if-statement, execute both the if-block and the else-block", then that's 100% conforming It is "conforming" to the spec that has made that part non-binding. It does not conform to "ignore the situation", because the unpredictable behavior mentioned in the spec is that of the environment, not the compiler.

nlewycky 3y ago
> Very clearly gives a list of "permissible behaviors" A statement like "we have products ranging from cake decorating to peanut crocheting to jousting lances" does not mean that this is a list of the only three types of items in the store. This construction is called a "false range" in English. When you have a range of something that does not have an order, it means "varied things, left unspecified". It's very clearly not supposed to be an exhaustive list, merely a few examples. So the standard lists three examples. The first is that the runtime behaviour of the program may do any-unpredictable-thing. The second is that the compiler may 'behave in a documented manner' and maybe issue an error. They wanted these two examples because they didn't want any misunderstanding that UB was limited to what could be shown UB statically at compile time, nor that it was limited to only having effects on the program at runtime. I'm not honestly sure why they bothered adding the third "oh, the compiler or the program terminates with an error message". I could speculate that this is what they wish would actually happen, and including it in the list improves the chance of that. > unpredictable behavior mentioned in the spec is that of the environment, not the compiler. I don't believe that's correct -- I think it appertains to the program not the environment or the compiler -- but it doesn't matter either way. The environment is responsible for supporting execution of the program, so if it's unpredictable then it follows that any unpredictable things can happen to your program -- it would be like trying to run on a CPU that's experiencing physical failures.
- mpweiher 3y ago
  > A statement like "we have products ranging from cake decorating to ... If you have a statement like that, that is likely true. However, this is not a statement like that. 1. It gives a range of 3 permissible options. If one of these "permissible" options is "you can do anything", what are the other 2 options doing on that list? 2. Even worse for your interpretation, the very word permissible only makes sense if there are things that are not permissible. So once again, "you can do anything" makes no sense. Both of these are non-sensical. Now had they actually written "you can do anything", this would be easy: they wrote nonsense. But they didn't write "you can do anything". What they actually wrote "ignoring the situation completely with unpredictable results". That this somehow (how?) means "I can do anything" is purely your interpretation. And your interpretation leads to nonsense. So clearly your interpretation is wrong, particularly when there is an alternative interpretation, that does not lead to nonsense. In addition, the "interpretation" that does not lead to nonsense is the one that takes the words literally. "Ignore the situation". Not "act on the situation and then do anything I damn well please". 3. Even a heterogenous range restricts. Yes, "we have products ranging from cake decorating to peanut crocheting to jousting lances" does not mean that those are the only items in the store. But even with your somewhat odd choice of items, if you go into that store and ask for an aircraft carrier, you will get odd looks, because the range of items mentioned clearly restricts the items they stock to non-aircraft carriers. > it would be like trying to run on a CPU that's experiencing physical failures. No, it is like reading beyond the range of an array: the machine will attempt to read fron that location, that may return a value, we don't know what value, or it may signal a fault. What it does is not defined by the standard, hence undefined behavior. It's not that* hard.
  - nlewycky 3y ago
    > 1. It gives a range of 3 permissible options. If one of these "permissible" options is "you can do anything", what are the other 2 options doing on that list? Before the list it clearly says, "behavior, [... when UB occurs elided ...], for which the Standard imposes no requirements." How can it both impose no requirements, yet simultaneously impose a requirement that it come out of that list of three options? > That this somehow (how?) means "I can do anything" is purely your interpretation. Purely mine? * https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=633 https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63... * https://blog.regehr.org/archives/213 https://blog.regehr.org/archives/213 * https://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html https://blog.llvm.org/2011/05/what-every-c-programmer-should... * https://stackoverflow.com/questions/32132574/does-undefined-behavior-really-permit-anything-to-happen https://stackoverflow.com/questions/32132574/does-undefined-... * https://en.wikipedia.org/wiki/Undefined_behavior#Examples_in_C_and_C++ https://en.wikipedia.org/wiki/Undefined_behavior#Examples_in... * https://www.youtube.com/watch?v=ehyHyAIa5so https://www.youtube.com/watch?v=ehyHyAIa5so I must have an amazing number of sock puppet accounts.

nlewycky 3y ago

> Very clearly gives a list of "permissible behaviors" A statement like "we have products ranging from cake decorating to peanut crocheting to jousting lances" does not mean that this is a list of the only three types of items in the store. This construction is called a "false range" in English. When you have a range of something that does not have an order, it means "varied things, left unspecified". It's very clearly not supposed to be an exhaustive list, merely a few examples. So the standard lists three examples. The first is that the runtime behaviour of the program may do any-unpredictable-thing. The second is that the compiler may 'behave in a documented manner' and maybe issue an error. They wanted these two examples because they didn't want any misunderstanding that UB was limited to what could be shown UB statically at compile time, nor that it was limited to only having effects on the program at runtime. I'm not honestly sure why they bothered adding the third "oh, the compiler or the program terminates with an error message". I could speculate that this is what they wish would actually happen, and including it in the list improves the chance of that. > unpredictable behavior mentioned in the spec is that of the environment, not the compiler. I don't believe that's correct -- I think it appertains to the program not the environment or the compiler -- but it doesn't matter either way. The environment is responsible for supporting execution of the program, so if it's unpredictable then it follows that any unpredictable things can happen to your program -- it would be like trying to run on a CPU that's experiencing physical failures.

mpweiher 3y ago
> A statement like "we have products ranging from cake decorating to ... If you have a statement like that, that is likely true. However, this is not a statement like that. 1. It gives a range of 3 permissible options. If one of these "permissible" options is "you can do anything", what are the other 2 options doing on that list? 2. Even worse for your interpretation, the very word permissible only makes sense if there are things that are not permissible. So once again, "you can do anything" makes no sense. Both of these are non-sensical. Now had they actually written "you can do anything", this would be easy: they wrote nonsense. But they didn't write "you can do anything". What they actually wrote "ignoring the situation completely with unpredictable results". That this somehow (how?) means "I can do anything" is purely your interpretation. And your interpretation leads to nonsense. So clearly your interpretation is wrong, particularly when there is an alternative interpretation, that does not lead to nonsense. In addition, the "interpretation" that does not lead to nonsense is the one that takes the words literally. "Ignore the situation". Not "act on the situation and then do anything I damn well please". 3. Even a heterogenous range restricts. Yes, "we have products ranging from cake decorating to peanut crocheting to jousting lances" does not mean that those are the only items in the store. But even with your somewhat odd choice of items, if you go into that store and ask for an aircraft carrier, you will get odd looks, because the range of items mentioned clearly restricts the items they stock to non-aircraft carriers. > it would be like trying to run on a CPU that's experiencing physical failures. No, it is like reading beyond the range of an array: the machine will attempt to read fron that location, that may return a value, we don't know what value, or it may signal a fault. What it does is not defined by the standard, hence undefined behavior. It's not that* hard.
- nlewycky 3y ago
  > 1. It gives a range of 3 permissible options. If one of these "permissible" options is "you can do anything", what are the other 2 options doing on that list? Before the list it clearly says, "behavior, [... when UB occurs elided ...], for which the Standard imposes no requirements." How can it both impose no requirements, yet simultaneously impose a requirement that it come out of that list of three options? > That this somehow (how?) means "I can do anything" is purely your interpretation. Purely mine? * https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=633 https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63... * https://blog.regehr.org/archives/213 https://blog.regehr.org/archives/213 * https://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html https://blog.llvm.org/2011/05/what-every-c-programmer-should... * https://stackoverflow.com/questions/32132574/does-undefined-behavior-really-permit-anything-to-happen https://stackoverflow.com/questions/32132574/does-undefined-... * https://en.wikipedia.org/wiki/Undefined_behavior#Examples_in_C_and_C++ https://en.wikipedia.org/wiki/Undefined_behavior#Examples_in... * https://www.youtube.com/watch?v=ehyHyAIa5so https://www.youtube.com/watch?v=ehyHyAIa5so I must have an amazing number of sock puppet accounts.