Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
> > Yes, this part introduced different behavior for this small case,
> >
> > int f(char *i, int j)
> > {
> > if (*i && j!=2)
> > return *i;
> > else
> > return j;
> > }
>
> Well, as far as I understand C specification and sequence points, it
> makes indeed a difference to do branch-cost optimization on instructions
> might cause a signal traps. As signal could be handled in specifc
> handlers. You need to consider here that short-circuit optimization
> assumes associative law on operands. So right-hand side might be
> evaluaded before the left-hand-side. And this indeed breaks IMHO the
> sequences as mentioned in C specification about conditions.
I'm not sure in this specific case. If it had been:
if (*a && *b) ...
the you'd be right. The side-effect of dereferencing a must happen before
*b, and hence transforming this into (*a!=0)&(*b!=0) would be wrong. But
in the case at hand we only have one potentially problematic (aka
detectable) side-effect (*i), so I don't think you could construct a
program that detects the difference. It would entail detecting that
"j!=2" was already evaluated, when (say) the segfault happens, but you
can't as the variable is non-volatile. It also can't happen that the
side-effect *i does not occur (which also would be a problem). So, I
think there wasn't an actual problem before, and it had fewer jumps.
Ciao,
Michael.
