Leaving aside the fact that that code reads an array out-of-bounds (which is not a trivial security issue) that's a ridiculously obtuse way to write that code. For loop conditions should be almost always be expressed in terms of their induction variable. A much cleaner and safe version is
int d[16];
int SATD (void)
{
int satd = 0, k = 0;
for (k = 0; k < 16; ++k)
satd += d[k] < 0 ? -d[k] : d[k];
return satd;
}I don't understand your logic though, according to my obviously inadequate understanding of UB, "k < 16" can never be false because its used as an array index for d[16]??? is the critical difference here that the array access happens outside of the "for" expression?
> Is the critical difference here that the array access happens outside of the "for" expression?
Precisely: this means that `d[k]` is guaranteed to execute before the check that `k < 16`. In general, if you have some access like `d[k]` where `k` is some integer and `d` is some array of size `N`, you can assume that `k < N` on all paths which are dominated by the statement containing `d[k]`. In simpler terms, the optimizer will assume that `k < N` is true on every path after the access to `d[k]` occurs.
To make this clearer, consider an equivalent, slightly-transformed version of the original code:
int d[16];
int SATD (void)
{
int satd = 0, dd, k;
dd = d[k=0];
do {
satd += (dd < 0 ? -dd : dd);
k = k + 1;
dd=d[k]; // At this point, k must be < 16.
} while (k < 16); // The value of `k` has not changed, thus our previous
// assumption that `k < 16` must still hold. Thus `k < 16`
// can be simplified to `true`.
return satd;
}
int d[16];
int SATD (void)
{
int satd = 0, k = 0;
k = 0;
do
{
satd += d[k] < 0 ? -d[k] : d[k]; // At this point, k must be < 16
k = k + 1;
} while (k < 16); // The value of `k` has changed -- at best, we can assert
// that `k < 17` since its value increased by 1 since we
// last assumed it was less than 16. But the assumption
// that `k < 16` doesn't hold, and this check cannot be
// simplified.
return satd;
}