Work around msvc definition of NAN

[bnoordhuis]

NAN is reportedly no longer a compile-time expression in some versions of MSVC. Work around that by minting a NaN from a uint64.

Fixes: #693

[saghul]

LoL, I took a stab at it here: #701

[saghul]

Would it make sense to define JS_FOLAT64_NAN like so?

[bnoordhuis]

Already exists and defined as follows :)

#define JS_FLOAT64_NAN NAN

edit: I suppose you're asking to change JS_FLOAT64_NAN? Won't work, you can't write it as a compile-time expression.

I initially named it JS_COMPILE_TIME_NAN but then I thought "rule of three" and there are only two instances now.

[saghul]

Can you herry pick the 1st commit from #701 so we can test if this is it?

[bnoordhuis]

Can you herry pick the 1st commit from #701 so we can test if this is it?

That doesn't build/pass CI though, does it?

[saghul]

Can you herry pick the 1st commit from #701 so we can test if this is it?

That doesn't build/pass CI though, does it?

The first commit is just the CI, which fails on master, if you add it here we'd know if your change fixes it :-)

[saghul]

If this works you also want to add a "Fixes" for #622

[bnoordhuis]

Oh, for posterity: another approach would have been to define them as e.g. 0.0/0.0 (and I guess that's still an option for JS_FLOAT64_NAN) but the benefit of bitcasting u64 to double is that it lets us control the exact NaN bit pattern.

[saghul]

Oh, for posterity: another approach would have been to define them as e.g. 0.0/0.0

I read in some other GH issue that that approach was no bueno for some reason with MSVC 🤷

but the benefit of bitcasting u64 to double is that it lets us control the exact NaN bit pattern.

TIL, makes sense!

[bnoordhuis]

Let's test it: #704 :)

[saghul]

Speaking of JS_FLOAT64_NAN is there a compelling reason to use that instead of NAN directly? I see more usages of the latter across quickjs.c

[bnoordhuis]

Not that I can see. I considered removing it but one thing at a time.