News for hackers. Stuff that matters.
Re:What is C in practice? by nothrabannosir on Monday June 29, 2015 @09:48PM (#9802376)
Yes, this is exactly the reason for undefined behavior. It is often overlooked in the "well, the compiler should just throw an error instead of invoking undefined behavior" debate: the compiler doesn't just "choose to invoke" undefined behavior: it relies on it to do program analysis.

For example, your example could legally be rewritten to:

    int x;
    f();
    x = 1;
    if (g()) { h(x); }
The only difference is if f() were false, and someone would then access x and see 1; but that's undefined behavior, so you can ignore it. In fact, assuming x is not accessible outside this block:

    f();
    if (g()) { h(1); }
These optimizations happen all over the place, it's not the compiler invoking or causing undefined behavior, but assuming that it won't ever happen.

EDIT: Note the further optimization that looms: if f() can be proven pure (no side effects), then it can be removed. This makes little sense for a function with no arguments (in which case it would just be a constant). If, however, f(y, ...) is some expensive but pure function, it can just be removed completely.

Re:What is C in practice? by dllthomas on Tuesday June 30, 2015 @11:47AM (#9806114)
"Note the further optimization that looms: if f() can be proven pure (no side effects), then it can be removed. This makes little sense for a function with no arguments (in which case it would just be a constant)."

It could apply if f computes a value based on global state but doesn't change anything, which is slightly weaker than "pure".