Caveat: GCC-based analysis unreliable for Free Software

Posted Jan 28, 2010 16:20 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]

I think a warning should be thrown even if just one argument has a side-effect on any other.

You know, that's closer to what I really meant. I guess I got in a hurry and didn't completely think through what I was suggesting. Basically, if any argument looks like it could potentially modify any other argument, flag it.

But to be honest a side-effect in argument passing should not even pass code reviews in the first place. Any side-effect deserves at least a (practically free) temporary variable.

I agree. There was a similar (but not identical) situation that bit me once when porting DOOM to one of our DSPs at work for a demo. In the case of DOOM, it wasn't argument order to a function call, but rather order of evaluation of terms in an expression.

The weird behavior I was seeing was that the built-in demo (which serves as something like a test case) wouldn't run correctly because the player and/or bad guys wouldn't take exactly the same course they did when the demo was recorded. The DOOM engine is supposed to be deterministic--if you run through the course in exactly the same way every time, then everything should behave identically.

DOOM has a "random number" function (P_Random()) that just returns the next unsigned byte out of a table of random bytes, keeping a pointer to which one is next. It resets this pointer at the start of the game. This allows the engine to ask for a "random" number and get a deterministic stream each time. That function was fine. The problem was with how it was being called.

There were several places in the code where the engine wanted a signed random number that had more of a triangular distribution. To get that, it would do this: P_Random()-P_Random() That idiom appears about a dozen places in the code.

You can guess what happened. GCC would make the two function calls in left-to-right order. Our DSP's compiler, however, made them in right-to-left order. *d'oh*

Same class of problem (getting burned by side effects where order isn't defined), just a different manifestation. It was this particular case I had in mind when I made my original comment. That said, your point is still quite valid. foo(x, ++x) is no better than foo(++x, ++x).