The problem is this definition of SvNVX from sv.h:

/* Need -0.0 for SvNVX to preserve IEEE FP "negative zero" because
   +0.0 + -0.0 => +0.0 but -0.0 + -0.0 => -0.0 */
#  define SvIVX(sv) (0 + ((XPVIV*) SvANY(sv))->xiv_iv)
#  define SvUVX(sv) (0 + ((XPVUV*) SvANY(sv))->xuv_uv)
#  define SvNVX(sv) (-0.0 + ((XPVNV*) SvANY(sv))->xnv_u.xnv_nv)
[download]

Their attempts to "preserve IEEE FP "negative zero"", performs + -0.0, which will *always* force SNaN to QNaN.

That said, there is conditional code for the 'F' and 'D' templates in pp_pack.c that bypasses SvNV (which uses SvNVX() if SvNOK is set) in favour of sv_2nv(), which ought to kick in on mingw builds:

#ifdef __GNUC__
        /* to work round a gcc/x86 bug; don't use SvNV */
        anv.nv = sv_2nv(fromstr);
#else
        anv.nv = SvNV(fromstr);
#endif
[download]

But that conditional is not present in 'd' template.

And in any case, sv_2nv() goes right ahead and uses SvNVX() if SvNOKp is set anyway:

Perl_sv_2nv_flags(pTHX_ SV *const sv, const I32 flags)
{
    dVAR;
    if (!sv)
    return 0.0;
    if (SvGMAGICAL(sv) || SvVALID(sv) || isREGEXP(sv)) {
    /* FBMs use the space for SvIVX and SvNVX for other purposes, and 
+use
       the same flag bit as SVf_IVisUV, so must not let them cache NVs
+.
       Regexps have no SvIVX and SvNVX fields.  */
    const char *ptr;
    if (flags & SV_GMAGIC)
        mg_get(sv);
    if (SvNOKp(sv))
        return SvNVX(sv);
[download]

so I don't quite see what purpose the conditional code above achieves ?

Bottom line: There is a bug -- or a combination of bugs -- that is preventing you getting your hands on an SNAN; but I don't think that it will be a quick fix.

Your best bet if you want to 'cure' the problem yourself is to bypass the Perl macros completely. The following won't work pre-5.10, and may not work on some later builds. (The latest version of 32-bit perl I have with inline installed is 5.8.9 and it doesn't work there.) And remember, if you touch the returned value with pack it will probably screw with it again. :

#! 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*get_snan() {
    SV *nv = newSVnv(0.0);
    *(unsigned __int64*)&( ((XPVNV*) SvANY(nv))->xnv_u.xnv_nv ) = i;
    return nv;
}

END_C

sub doubleToHex { scalar reverse unpack 'h16', pack 'd', $_[0] }

my $snan = get_snan();

printf "%f\n", $snan;

print doubleToHex( $snan );
[download]

Their attempts to "preserve IEEE FP "negative zero"", performs + -0.0, which will *always* force SNaN to QNaN

Yes - that does seem pretty general behaviour, but I'm not concerned about that.
In fact, I've come to the view that if an operation involving an SNAN does not throw an exception then the result might just as well be a QNAN - since the SNAN is effectively quiet anyway.
Perhaps that's the rationale behind the behaviour.

I see no reason to expect that an operation involving an SNAN cannot not return a QNAN when no exception is thrown and I can even see a case for propagating the SNAN as a QNAN.
However, I don't know what the relevant IEEE standards stipulate - and, obviously if this behaviour contravenes said standards then the behaviour should be changed.

The following won't work pre-5.10, and may not work on some later builds

On 32-bit 5.22.0, 5.24.0 and latest blead the NV still gets set to 7ff8000000000001. (I didn't try any other perl versions.)

I don't personally need to be able to assign a double with internal representation of 7ff0000000000001, though I do think it's at least worth raising awareness of this bug in the 32-bit Windows builds.
But first I'll make a concerted effort to find a way to make that assignment.

Cheers,
Rob

You miss my point; or more likely I didn't make it clear enough.

The point is that it is trivial to assign a signalling NaN to an NV; the problem arises when you try to verify/prove that you've done so. because having got the value in there, in order to access it, almost any code you use to get access to the NV (including unpack), will use SvNVX(), and that macro performs the (pointless) floating point addition, which will mean the SNaN will have been coerced to a QNaN before you can check that the assignment was successful; thus you will forever think the assignment failed, when in fact it succeeded, and it is only the attempt to verify it fails.

Though I suppose another view might be: can you judge the assignment to be successful, if you can never get the value you assigned, back, without it having been corrupted.

Either of these should produce an SNaN under 32-bit:

printf "%f\n", unpack 'd', pack 'VV', 0x00000001, 0x7FF00000;;
1.#QNAN0

printf "%f\n", unpack 'F', pack 'VV', 0x00000001, 0x7FF00000;;
1.#QNAN0
[download]

They don't, because the unpack (via the SvNVX() macro) adds -0.0 to the value generated by the pack. And that's a bug.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice. Not understood.