Re: Large number bytecode weirdness on different platforms
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Large number bytecode weirdness on different platforms
- From: Chris <coderight@...>
- Date: 2007年1月29日 17:01:53 -0500
Just to followup, I added the following patch to lobject.c which seems
to work. I also went ahead and converted to strtoull on the non-MSVC
platforms since that seems to make sense with the double being large
and all (does Cygwin support strtoull?). I'm surprised it worked on
Linux since strtol only returns a long and I'm on a 32-bit platform.
--- lobject.c.orig 2007年01月29日 16:54:42.809355761 -0500
+++ lobject.c 2007年01月29日 16:55:03.856823052 -0500
@@ -92,7 +92,11 @@
*result = lua_str2number(s, &endptr);
if (endptr == s) return 0; /* conversion failed */
if (*endptr == 'x' || *endptr == 'X') /* maybe an hexadecimal constant? */
- *result = cast_num(strtoul(s, &endptr, 16));
+#ifdef _MSC_VER
+ *result = cast_num((unsigned _int64)_strtoi64(s, &endptr, 16));
+#else
+ *result = cast_num(strtoull(s, &endptr, 16));
+#endif
if (*endptr == '0円') return 1; /* most common case */
while (isspace(cast(unsigned char, *endptr))) endptr++;
if (*endptr != '0円') return 0; /* invalid trailing characters? */
On 1/29/07, Chris <coderight@gmail.com> wrote:
As you mentioned it looks like the Windows version is overflowing.
Ah, now I see it's a problem with the "0x" hex parsing because if I
use the normal integer value there is no problem. Ugh, I hate
inconsistent behaviour ;)