On Sun, Mar 18, 2012 at 1:08 AM, Florian Hester<florian@celaeno.org> wrote:
So, am i doing something which i simply should not be doing, debugging or
otherwise, or is there truly something screwy going on?
I believe that your Windows liblua.a is using NaN-packed 8-byte
TValues, while your main.c is picking up the definitions for naive
16-byte TValues. If the Linux output is placed along-side the Windows
output, and each line of Windows output is paired with two lines of
Linux output, then we get the following:
gc pointer: 0x23f3fe0 N/A
gc pointer: 0x23f4030 gc pointer: 003e4140
gc pointer: 0x23f4030 N/A
str value: Foo gc pointer: 003e37b0
nr value: 5.200000 N/A
nr value: -3.223000 gc pointer: 39581062
str value: Foo N/A
nr value: 10.823300 gc pointer: 93dd97f6
str value: Bar N/A
gc pointer: 0x23f40e0 gc pointer: 003e41a8
gc pointer: 0x23f4130 N/A
N/A gc pointer: baadf00d
N/A N/A
N/A gc pointer: baadf00d
...
If your Windows TValues were indeed NaN-packed then your type code
extraction will almost certainly give a random value, explaining why
it always said "gc pointer". Furthermore, number values would almost
certainly not look like heap pointers, while non-number values would
look like heap pointers. Finally, pointers beyond the end of memory
would come out as a sentinel value. All of these things match what is
seen.
