scan from string %d double float - WHAT???

[TroyK]

I realise I'm asking for trouble using "scan from string" with %d as the format string and giving it a double as the default value type, but I certainly did not expect this result.  3013981218 does not equal -1280986078.

Looks like a bug to me (LV2011SP1-LV2015). Can anyone explain this?

When I say that the value that comes out of the typecast is expected, I mean I can expect something strange.

What I did not expect was that scanning an integer string to a double using %d would give me the same result as the weird typecast.

[Sam_Sharp]

Interestingly, it's got something to do with the 32-bit numbers. 2147483648 (2^31) is the first number where you don't get the expected result, but 2147483647 (2^31 - 1) works. I'm not sure if this is OS dependent or that scan from string converts it to a 32-bit number and then converts (or type casts?) to a DBL internally.

[crossrulz]

I am pretty sure the %d is parsed to an U32 internally and then casted into whatever value from there.  This was discussed somethere, I think in the Idea Exchange.

[TroyK]

If %d is parsed internally to a U32 (as you would expect) then I should get the correct value out.

What comes out appears to be that U32 value type cast to an I32.

The actual byte data is the same obviously, it just seems to be assuming it is an I32 not a U32. It takes the most significant bit and assumes its a sign bit, not part of the value.

This behaviour is unexpected.

[Sam_Sharp]

Since a %d can be a negative number, I'm pretty sure it's converted to an I32 internally and then to a double. I agree that it is not expected behaviour though - perhaps raise a ticket with NI and get a CAR number?

Question - why don't you scan to a float (%f) and then round? That would give the correct results?

[crossrulz · Accepted solution]

Ok, it is I32.  Here is the post I was thinking about: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Upgrade-format-string-s-quot-d-quot-behavior-to-serve-...

[TroyK]

---

Sam_Sharp wrote: why don't you scan to a float (%f) and then round? That would give the correct results?

---

Yes, that's what I've changed it to. It was an old bit of code that that hadn't looked at in years until I realized it misbehaved with large integers.