By registering with us, you'll be able to discuss, share and private message with other members of our community.
SignUp Now!It's 0/10. But doesn't that deal with what comes after a decimal point?What's your EVAL precision?
Yeah, but 18446744073709551615 is 0xFFFFFFFFFFFFFFFF and treated an signed, that's -1.Hex values (like integer operators) are int64 (signed 64-bit) max.
v:\> echo %@eval[18446744073709551615=x]
0x7FFFFFFFFFFFFFFF
Yeah, but 18446744073709551615 is 0xFFFFFFFFFFFFFFFF and treated an signed, that's -1.
0x7FFFFFFFFFFFFFFF is the largest positive signed int64, 9223372036854775807. I still can't figure out where it's coming from.
I see. _wcstoi64() does the same thing. I still think it's odd. 0 would be a better indication that something of an error (overflow) than _I64_MAX.It's coming from the RTL (_wtoi64).
1. It's just not very informative.I'm not sure I understand why you think it's odd -- you're passing in an argument that's twice the maximum allowed size, and it's getting truncated (by the RTL).
Do you actually need to convert 64-bit values to hex?
I already have @CONVERT, which gets it right.Apparently not too occasionally, or you would have mentioned it a few years ago!
I'm afraid you're on your own here -- you can write your own function to do the > 2*64 hex conversions. (But it will not be easy.)
v:\> echo %@eval[2**64-1]
18446744073709551615
v:\> echo %@convert[10,16,18446744073709551615]
FFFFFFFFFFFFFFFF
Well I don't know how it does it but @CONVERT correctly turns 18446744073709551615 (which is less than 2**64) into FFFFFFFFFFFFFFFF. And it turns 18446744073709551614 into FFFFFFFFFFFFFFFE. And so on. Maybe @EVAL's "=x" should assume a positive number is desired and use @CONVERT.@CONVERT won't work with anything > 2**64, as it also uses int64 variables.