3 ms·

They're undefined. (From a quick skim.) However, an implementation could define various UBs however it wants. The difference between "undefined" and "implement

They're undefined. (From a quick skim.) However, an implementation could define various UBs however it wants. The difference between "undefined" and "implement-defined" is really that an implementation doesn't have to anything even remotely sensible for "undefined" behavior, but it has do define some ("sensible") behavior for "implementation-defined" behavior. Usually, "implementation-defined" behavior also tends to remain consistent across versions whereas "undefined" behavior usually has no such constraints. For example, for "undefined" behavior, version 5.1.2.3 of the compiler may differ drastically from 5.1.2.4 in terms of optimizations which rely on UB.

Sharlin 10y ago
Basically: Undefined - the compiler may assume this can never happen, and if it does happen, it can "poison" the whole execution including whatever logically happens before the undefined part. Unspecified - the behavior must be deterministic and cannot affect the semantics of other well-defined parts of the program, but the implementation need not guarantee any single behavior. Implementation-specified - like above, but the implementation must specify the exact behavior.
- to3m 10y ago
  The compiler may also assume undefined behaviour can happen, and do something documented, that programmers would probably expect. Even though the standard imposes no specific requirements, it explicitly calls that out at something you could do: http://port70.net/~nsz/c/c11/n1570.html#3.4.3 http://port70.net/~nsz/c/c11/n1570.html#3.4.3 But for some reason nobody seems to ever think this is an option.
  - lmm 10y ago
    It wouldn't improve benchmark performance, which is what C compiler writers care about. And at this point in time any programmer who wants that kind of behaviour has probably moved on from C.
    - lomnakkus 10y ago
      Well, that and undefined behavior sometimes would require absurd amounts of runtime checking (eg. on signed bit shifts, etc.).

Sharlin 10y ago

Basically: Undefined - the compiler may assume this can never happen, and if it does happen, it can "poison" the whole execution including whatever logically happens before the undefined part. Unspecified - the behavior must be deterministic and cannot affect the semantics of other well-defined parts of the program, but the implementation need not guarantee any single behavior. Implementation-specified - like above, but the implementation must specify the exact behavior.

to3m 10y ago
The compiler may also assume undefined behaviour can happen, and do something documented, that programmers would probably expect. Even though the standard imposes no specific requirements, it explicitly calls that out at something you could do: http://port70.net/~nsz/c/c11/n1570.html#3.4.3 http://port70.net/~nsz/c/c11/n1570.html#3.4.3 But for some reason nobody seems to ever think this is an option.
- lmm 10y ago
  It wouldn't improve benchmark performance, which is what C compiler writers care about. And at this point in time any programmer who wants that kind of behaviour has probably moved on from C.
  - lomnakkus 10y ago
    Well, that and undefined behavior sometimes would require absurd amounts of runtime checking (eg. on signed bit shifts, etc.).