In C or C++ this code invokes "undefined behavior" (behavior that is not defined by the C standard) because it relies on the order of evaluation of two sub-expressions that reside within the same sequence point. The == relational operator in C does not form a sequence point. But the = has a side effect. We cannot know (based on the C or C++ standards) what the order of evaluation will be when there is no sequence point defining the order. Therefore, we cannot know when the side effects will be applied. (See http://en.wikipedia.org/wiki/Sequence_point.)

With C or C++, when the behavior is not defined by the standard, it is quite possibly different between various implementations, and in any implementation, could be surprising.

Language lawyers in the C or C++ worlds love to shake their heads in condescending scorn when they see code that unknowingly invokes undefined behavior. Even with Perl, this is that sort of code; within the same sequence point, there is no formal definition of the order in which subexpressions will be evaluated. These subexpressions have side effects, and we cannot know when the side effects will take effect.

With Perl we can reason about what probably will happen because the implementation is often accepted as the definition. But eq still doesn't form a sequence point, and in the absence of an explicit rule, I think this is one to avoid trusting in real code. It's still pretty much "undefined behavior".