3 ms·

There's a note in the C99 rationale explaining how compilers can use undefined behavior (specifically, with regards to signed overflow) to perform certain optim

There's a note in the C99 rationale explaining how compilers can use undefined behavior (specifically, with regards to signed overflow) to perform certain optimizations (specifically, reassociation of integer addition). I'd go back to C89, but the documents before the work effort to make C99 are not available on the WG14 website. > I do however expect the compiler documentation to have an extensive section on stuff undefined by the specification. There is an entire section of the C specification that lists every single undefined behavior. What more do you want?

kps 4y ago
https://www.lysator.liu.se/c/rat/title.html https://www.lysator.liu.se/c/rat/title.html has the C89 Rationale. “The terms unspecified behavior, undefined behavior, and implementation-defined behavior are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe. […] Undefined behavior gives the implementor license not to catch certain program errors that are difficult to diagnose.”
- jcranmer 4y ago
  For the commentary on undefined behavior, I find N790 (https://www9.open-std.org/jtc1/sc22/wg14/www/docs/n790.htm https://www9.open-std.org/jtc1/sc22/wg14/www/docs/n790.htm) to be a better assessment of what the C committee thinks about undefined behavior: First consider the term "unspecified behavior". Most commentators on the Standard are of the opinion that this has the following properties: (1) There are a number of possible courses of actions, or the behavior is one that generates a result and then has a number of possible results. (2) The implementation can make any of the available choices, and can make different choices at different places or times. (3) The implementation need not document its choices. (4) No matter what choice the implementation makes, it cannot affect anything outside the range of that choice. If a value has to be chosen, it must be a valid value for that type. Property number 4 is the interesting one: it is usually taken to mean that the implementation cannot generate a spurious signal, branch to a random place in the code, or choose a trap representation. All of these, of course, are valid "undefined behavior".
deleted 4y ago
[deleted]
somat 4y ago
My thought process, note that I am not a compiler writer, runs along these lines. undefined behavior is valid code(it is not a syntax error), it has to do some thing, that thing should be documented, if the spec does not want to document it, then the implementation should. don't make the assumption that because it is undefined it will never happen.
- jcranmer 4y ago
  It is not practical to constrain what happens in the case of undefined behavior, even if you discard the potential of the compiler to optimize assuming undefined behavior can't happen. For example, what memory has and hasn't been written when a trap occurs isn't. Hell, on some architectures (hi Alpha!), an unknown amount of code will continue executing after the trapping instruction before the trap handler gets around to being invoked. Similar insanity is also in play when data races are involved (if data races are undefined, you can pretend that all code is sequentially consistent and there is a nice, simple, global total order of memory accesses. Data races cause memory accesses to not even be a consistent partial order.) Or take pointer provenance. Writing to an unknown memory location may cause printf in another thread to instead call system("rm -rf /"). How the hell is one supposed to document the potential behavior of undefined behavior when undefined behavior is so inherently unconstrainable, and "undefined behavior can do anything" is considered unacceptable documentation?
- pklausler 4y ago
  What you're talking about is "implementation defined" behavior, which is a distinct concept from "undefined behavior".
fsckboy 4y ago
>> "specification left this undefined so that the compiler can define it" >> I do however expect the compiler documentation to have an extensive section on stuff undefined by the specification and he should have said which is defined by the compiler so your response is not to what he meant > There is an entire section of the C specification that lists every single undefined behavior. What more do you want? a similar section wrt the compiler he is using, because he's talking about "behavior undefined by C but defined by implementation"
- jcranmer 4y ago
  > a similar section wrt the compiler he is using, because he's talking about "behavior undefined by C but defined by implementation" That's called implementation-defined behavior. And there is a section in C that lists all the implementation-defined behavior, and all the compilers are supposed to document what they define the implementation-defined behavior to be (glares at Clang).

kps 4y ago

https://www.lysator.liu.se/c/rat/title.html https://www.lysator.liu.se/c/rat/title.html has the C89 Rationale. “The terms unspecified behavior, undefined behavior, and implementation-defined behavior are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe. […] Undefined behavior gives the implementor license not to catch certain program errors that are difficult to diagnose.”

jcranmer 4y ago
For the commentary on undefined behavior, I find N790 (https://www9.open-std.org/jtc1/sc22/wg14/www/docs/n790.htm https://www9.open-std.org/jtc1/sc22/wg14/www/docs/n790.htm) to be a better assessment of what the C committee thinks about undefined behavior: First consider the term "unspecified behavior". Most commentators on the Standard are of the opinion that this has the following properties: (1) There are a number of possible courses of actions, or the behavior is one that generates a result and then has a number of possible results. (2) The implementation can make any of the available choices, and can make different choices at different places or times. (3) The implementation need not document its choices. (4) No matter what choice the implementation makes, it cannot affect anything outside the range of that choice. If a value has to be chosen, it must be a valid value for that type. Property number 4 is the interesting one: it is usually taken to mean that the implementation cannot generate a spurious signal, branch to a random place in the code, or choose a trap representation. All of these, of course, are valid "undefined behavior".

deleted 4y ago

[deleted]

somat 4y ago

My thought process, note that I am not a compiler writer, runs along these lines. undefined behavior is valid code(it is not a syntax error), it has to do some thing, that thing should be documented, if the spec does not want to document it, then the implementation should. don't make the assumption that because it is undefined it will never happen.

jcranmer 4y ago
It is not practical to constrain what happens in the case of undefined behavior, even if you discard the potential of the compiler to optimize assuming undefined behavior can't happen. For example, what memory has and hasn't been written when a trap occurs isn't. Hell, on some architectures (hi Alpha!), an unknown amount of code will continue executing after the trapping instruction before the trap handler gets around to being invoked. Similar insanity is also in play when data races are involved (if data races are undefined, you can pretend that all code is sequentially consistent and there is a nice, simple, global total order of memory accesses. Data races cause memory accesses to not even be a consistent partial order.) Or take pointer provenance. Writing to an unknown memory location may cause printf in another thread to instead call system("rm -rf /"). How the hell is one supposed to document the potential behavior of undefined behavior when undefined behavior is so inherently unconstrainable, and "undefined behavior can do anything" is considered unacceptable documentation?
pklausler 4y ago
What you're talking about is "implementation defined" behavior, which is a distinct concept from "undefined behavior".

fsckboy 4y ago

>> "specification left this undefined so that the compiler can define it" >> I do however expect the compiler documentation to have an extensive section on stuff undefined by the specification and he should have said which is defined by the compiler so your response is not to what he meant > There is an entire section of the C specification that lists every single undefined behavior. What more do you want? a similar section wrt the compiler he is using, because he's talking about "behavior undefined by C but defined by implementation"

jcranmer 4y ago
> a similar section wrt the compiler he is using, because he's talking about "behavior undefined by C but defined by implementation" That's called implementation-defined behavior. And there is a section in C that lists all the implementation-defined behavior, and all the compilers are supposed to document what they define the implementation-defined behavior to be (glares at Clang).