Hello BrowserUk,

At first glance some will be surprised that it is the body of the equal (==) comparison that has been optimised away completely and the body of the unequal (!=) comparison that has been left behind...

Yes, I was, until I found it documented in perlop#Equality-Operators:

If your platform supports NaN 's (not-a-numbers) as numeric values, using them with "<=>" returns undef. NaN is not "<", "==", ">", "<=" or ">=" anything (even NaN), so those 5 return false. NaN != NaN returns true, as does NaN != anything else. If your platform doesn't support NaN 's then NaN is just a string with numeric value 0.

I guess that’s logical: if something is not a number then using it in a numeric comparison doesn’t make much sense.

But then I realised that there isn't a floating point constant that can be embedded as source code that will translate to SNAN. That's why I need to use pack/unpack to define it.

I note that on my system (Windows 8.1, Strawberry Perl 5.24.0, 64-bit, with USE_LONG_DOUBLE defined) the call to pack is also optimised away:

17:44 >perl -MO=Deparse -le"use constant SNaN => unpack'd', pack'Q',0x
+7ff0000000
000001; print SNaN; if( SNaN != SNaN ) { print 'here'; }"
BEGIN { $/ = "\n"; $\ = "\n"; }
use constant ('SNaN', unpack('d', "\cA\000\000\000\000\000\360\177"));
print unpack("F", pack("h*", "008000000000000cfff7000000000000"));
do {
    print 'here'
};
-e syntax OK

17:45 >perl -MO=Deparse -le"use constant SNaN => unpack'd', pack'Q', 0
+x7ff000000
0000001; print SNaN; if( SNaN == SNaN ) { print 'here'; }"
BEGIN { $/ = "\n"; $\ = "\n"; }
use constant ('SNaN', unpack('d', "\cA\000\000\000\000\000\360\177"));
print unpack("F", pack("h*", "008000000000000cfff7000000000000"));
'???';
-e syntax OK

17:46 >
[download]

Hope that’s of interest,