[Peter Ebbesen]

Originally posted by Arryn:
The problem comes in that the compiler's optimization will substitute the same call to the random number function for both die rolls. It won't make the two rand() calls the coders intend. What it does is make one call and plug the same value into both places. The optimizer does not know that in this circumstance, two calls to the same function do not return the same value.

That would be an exceedingly poorly written optimizer. I certainly did not understand that as the original problem. I am certain that any decent compiler would make the two rand calls.

As I understood it, the real problem was that in the expression "a < b" the order of evaluation of "a" and "b" is undefined [Ansi-C, and its derivatives, with a few exceptions only specifies the order of evaluation for operators, not for sub-expressions]. Either side "a" or "b" can be evaluated first.

Given that the seed is the same, assume the RNG will return R1 and R2 over the next two calls in that order. Then the inequality:

(penetration+2d6 < MR+2d6)

can legally be compiled such that the evaluation is either of the following:
penetration+R1 < MR+R2 (left hand side evaluated first)
penetration+R2 < MR+R1 (right hand side evaluated first)

- Which may or may not give different return values.

Changing the inequality as AStott suggested, to
penetration < MR+2d6-2d6
would not necessarily solve the problem either, as the order of evaluation of the two 2d6 function calls is not defined either. (The order of the addition and subtraction is, but not the order of evaluation of the sub-expressions)

If you are in doubt, split such expressions over multiple commands independently evaluated. A bad optimizer may still hurt you, but at least you won't be bitten by the "undefined evaluation order", which is nobody's fault but your own. Or, to quote Kernigham & Ritchie:

The moral is that writing code that depends on order of evaluation is a bad programming practice in any language. Naturally, it is necessary to know what things to avoid, but if you don't know how they are done on various machines, you won't be tempted to take advantage of a particular implementation.

[ February 25, 2004, 23:23: Message edited by: Peter Ebbesen ]