your "improved" version illegally modifies 'i' twice in the same statement; its results are undefined.

You are right. But there are two outcomes I think are likely. The ++ could happen either before or after the * . Under either outcome the loop is finite in theory but not practice.

The possibility that I consider unlikely, of course, is that I've broken some assumption that causes the compiler to optimize cause an entirely undefined third behavior (such as crashing). Then the outcome is undefined. That is the kind of implementation detail that code golf often brushes against. I'm not sure whether a solution that includes that possibility but which happens to work on, say, gcc is considered legal.

But that suggests the following unambiguous form:

    int i,x[99];for(x[98]=i=1;x[98];)i*=!++x[++i];

> But there are two outcomes I think are likely.

It's undefined behavior. Any outcome is likely. The compiler could halt your program immediately if it wanted to, and that's just as likely as either of the cases you offer.

That's still not unambiguous. Turn -Wall on and you'll be told the operation on 'i' may be undefined.

And you could save an additional character by changing the loop test to a+b form, i.e.:

int i,x[99];for(x[98]=i=1;x+98;)i*=!++x[i++];

The other array references are l-values.

That would need to be *(x+98), which is longer than x[98].

Ahh.. you're right, of course. What I wrote has an undefined termination condition, besides not being consistent with the original algo. Thanks.