Yes - how do we conclusively determine whether the bug is in the assigning, or in the retrieving ?

The best I can think of is the IC code below. It returns an SV that has SvNOK set and the NV contains an SNaN bit pattern.

It does two things that are a bit trick (and non-portable to earlier (<5.10) builds because of changes to perl's internal structures over the last several builds.)

1. It assigns the bit pattern to the NV field of the SV directly, bypassing any/all internal macros that might mess with it.
2. It points the PV pointer at the memory containing the NV allowing direct access from perl without unpack 'd'/'F'

It *may* be possible to port it to gcc/32-bit?

#! perl -slw
use strict; use Config;
use Inline C => Config => BUILD_NOISY => 1, CCFLAGS => $Config{ccflags
+}." -DDEBUG=1";
use Inline C => <<'END_C',  NAME => 'ICexample', CLEAN_AFTER_BUILD =>0
+;

static const unsigned __int64 i = 0x7ff0000000000001;

SV*snan2() {
    // Allocate a new SvPV with some junk pv data
    SV *ret = newSVpvn( "JustJunk", 8 );

    // Assign the SNaN bit pattern directly to the NV field bypassing 
+any dodgy macros
    *(unsigned __int64*)&( ( (XPVNV*)ret->sv_any )->xnv_u.xnv_nv ) = i
+;

    // Set the NOK flag
    SvNOK_on( ret );

    // Now point the PV pointer directly at the NV memory so we can ac
+cess it
    // (the NV) from perl without going through pack 'd'/'F'
    SvPV_set( ret, (char*)&( ( (XPVNV*)ret->sv_any )->xnv_u.xnv_nv ) )
+;

    // make it persist
    SvREFCNT_inc_void_NN( ret );
    
    // Make sure noone can mess with it.
    SvREADONLY( ret );
    return ret;
}

END_C

## Get an SNAN.
my $snan2 = snan2();

##Print its numeric value AND its bit pattern bypassing SVNV?()
printf "%f\n%x\n", $snan2, unpack 'Q', $snan2;

## Same thing as the printf '%x', unpack 'Q' above
## that *might* work on 32-bit that doesn't have Q
print scalar reverse unpack 'h*', $snan2;

__END__
C:\test>snan-ic.pl
1.#SNAN0
7ff0000000000001
7ff0000000000001
[download]