7 ms·

> Even if the behavior is "undefined" as per standard, that doesn't mean that any compiler should "define" its own interpretation and implementation in a way to

> Even if the behavior is "undefined" as per standard, that doesn't mean that any compiler should "define" its own interpretation and implementation in a way to make every resulting program worse. The standard offers no interpretation of any undefined behavior, that's literally what meant by undefined. There is no execution of a program that contains UB that could be considered 'valid' by the standard. The compiler has no choice, it has to define its own interpretation.

eru 7y ago
To make matters worse, undefined behaviour doesn't just exist at runtime. It can also happen at compile time etc. And it is allowed to time travel.
acqq 7y ago
> The standard offers no interpretation of any undefined behavior "The standard" is not compiling my program, the real compiler is doing that, and the authors of that specific implementation should do the right thing, in spite of the standard leaving something "undefined." > The compiler has no choice, it has to define its own interpretation. Correct. And it can define it as to not to be an adversary to the writer of the code.
- ryandrake 7y ago
  What is the “right” thing to do with UB, and who defines what is right, if not the standard? You?
  - acqq 7y ago
    > What is the “right” thing to do with UB It is actually quite clear in most of specific cases, as Linus pointed even 18 years ago: https://gcc.gnu.org/legacy-ml/gcc/2002-01/msg00418.html https://gcc.gnu.org/legacy-ml/gcc/2002-01/msg00418.html "When it comes to optimization, there are things that are "obvious", and that will never generate any discussion at all, because they are faster ways of getting the exact same result, with no question about it. Nobody will ever fault a compiler for evaluating constant expressions at compile-time rather than doing the math at run-time and getting the same result. The two are indistinguishable from a result standpoint. But optimizations that can change the value of an expression are slightly different. They should make sense. You should be able to _explain_ them." "If you cannot explain the results, you end up having to argue about word-weaseling in the standard, and people _will_ disagree on what the damn thing means. Because standards aren't mathematically exact things."
- MaxBarraclough 7y ago
  > it can define it as to not to be an adversary to the writer of the code. We see peculiar things happen when there's undefined behaviour, because of the way compilers' optimisers work. It would be possible to tame the way undefined behaviour manifests, but this would trade off against the compiler's ability to optimise. If that weren't the case, everyone would be doing it.
imtringued 7y ago
The unsigned short to signed int promotion is an example of "compiler-manufactured" UB. The compiler could have chosen a type promotion that does not cause UB.
- aw1621107 7y ago
  I believe compilers are constrained by a combination of ABI and the standard here. Section 6.3.1.1 of the C11 draft states [0]: > If an int can represent all values of the original type (as restricted by the width, for a bit-field), the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions. All other types are unchanged by the integer promotions. So the type that the compiler promotes to is determined entirely by the widths of unsigned short and signed int, which in turn are defined by the ABI. There is no room for picking a different promotion here. [0]: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf
MaxBarraclough 7y ago
> The standard offers no interpretation of any undefined behavior, that's literally what meant by undefined Correct. > There is no execution of a program that contains UB that could be considered 'valid' by the standard. That strikes me as backward. It would be more correct to say There is no execution of a program that contains UB that could be considered 'invalid' by the standard. Even this isn't quite precise enough though. If there's undefined behaviour in a function which is never used, that doesn't cause the program to have undefined behaviour. > The compiler has no choice, it has to define its own interpretation. No, it doesn't. That's only true of implementation-defined behaviour. In the case of undefined behaviour, the program doesn't even have to behave the same way every time. https://en.wikipedia.org/wiki/Unspecified_behavior#Implementation-defined_behavior https://en.wikipedia.org/wiki/Unspecified_behavior#Implement...

eru 7y ago

To make matters worse, undefined behaviour doesn't just exist at runtime. It can also happen at compile time etc. And it is allowed to time travel.

acqq 7y ago

> The standard offers no interpretation of any undefined behavior "The standard" is not compiling my program, the real compiler is doing that, and the authors of that specific implementation should do the right thing, in spite of the standard leaving something "undefined." > The compiler has no choice, it has to define its own interpretation. Correct. And it can define it as to not to be an adversary to the writer of the code.

ryandrake 7y ago
What is the “right” thing to do with UB, and who defines what is right, if not the standard? You?
- acqq 7y ago
  > What is the “right” thing to do with UB It is actually quite clear in most of specific cases, as Linus pointed even 18 years ago: https://gcc.gnu.org/legacy-ml/gcc/2002-01/msg00418.html https://gcc.gnu.org/legacy-ml/gcc/2002-01/msg00418.html "When it comes to optimization, there are things that are "obvious", and that will never generate any discussion at all, because they are faster ways of getting the exact same result, with no question about it. Nobody will ever fault a compiler for evaluating constant expressions at compile-time rather than doing the math at run-time and getting the same result. The two are indistinguishable from a result standpoint. But optimizations that can change the value of an expression are slightly different. They should make sense. You should be able to _explain_ them." "If you cannot explain the results, you end up having to argue about word-weaseling in the standard, and people _will_ disagree on what the damn thing means. Because standards aren't mathematically exact things."
MaxBarraclough 7y ago
> it can define it as to not to be an adversary to the writer of the code. We see peculiar things happen when there's undefined behaviour, because of the way compilers' optimisers work. It would be possible to tame the way undefined behaviour manifests, but this would trade off against the compiler's ability to optimise. If that weren't the case, everyone would be doing it.

imtringued 7y ago

The unsigned short to signed int promotion is an example of "compiler-manufactured" UB. The compiler could have chosen a type promotion that does not cause UB.

aw1621107 7y ago
I believe compilers are constrained by a combination of ABI and the standard here. Section 6.3.1.1 of the C11 draft states [0]: > If an int can represent all values of the original type (as restricted by the width, for a bit-field), the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions. All other types are unchanged by the integer promotions. So the type that the compiler promotes to is determined entirely by the widths of unsigned short and signed int, which in turn are defined by the ABI. There is no room for picking a different promotion here. [0]: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf

MaxBarraclough 7y ago

> The standard offers no interpretation of any undefined behavior, that's literally what meant by undefined Correct. > There is no execution of a program that contains UB that could be considered 'valid' by the standard. That strikes me as backward. It would be more correct to say There is no execution of a program that contains UB that could be considered 'invalid' by the standard. Even this isn't quite precise enough though. If there's undefined behaviour in a function which is never used, that doesn't cause the program to have undefined behaviour. > The compiler has no choice, it has to define its own interpretation. No, it doesn't. That's only true of implementation-defined behaviour. In the case of undefined behaviour, the program doesn't even have to behave the same way every time. https://en.wikipedia.org/wiki/Unspecified_behavior#Implementation-defined_behavior https://en.wikipedia.org/wiki/Unspecified_behavior#Implement...