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".

Result is that it gives is "equal". Why?

Because eq is a function with infix syntax. That is:  a eq b is actually eq( a, b ).

Thus, by the time eq() sees the parameters, both assignments have been done, and it just gets two copies of the (same) final value.

Viz

sub eq{ print "@_"; $_[0] eq $_[1] };;

print eq( $x=1, $x=2 );;
Ambiguous call resolved as CORE::eq(), qualify as such or use & at (ev
+al 13) line 1, <STDIN> line 5.
Use of uninitialized value $_ in print at (eval 13) line 1, <STDIN> li
+ne 5.

print &eq( $x=1, $x=2 );;
2 2
1
[download]

Both assignments have to have been performed before the eq is evaluated so chances are eq is seeing the same value for $x. However there is no guarantee that that will be the case. The compiler could choose to cache the value from the left expression in which case the result would be false.

As you hint, that is fundamentally broken code - in any context!

use strict;
use warnings;

my $x = 1;
my $y = 2;

if($x == $y) {
 print "equal\n";
} else {
 print "not equal\n";
}
[download]