lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

If size_t is anyways expected to be 32-bits (minimum) why even store it in the Lua identification block?

Just expect 32-bit string lengths, take sizeof(size_t) away from the identifier.

Luiz Henrique de Figueiredo kirjoitti 4.4.2008 kello 13:13:

But you may want to change this if you change ldump.c (but not if you only
change lundump.c).

*h++=(char)*(char*)&x;                         /* endianness */
I found this lundump.c-patch by lhf regarding this issue:

This only caters for the big-endian x little-endian issue. It does not
handle strange byte orders, but can be made to, of course. Just save more
information in that field instead of just the boolean value above.

So in what way does size_t (the pointer size) affect the byte-code files

size_t is used for string lengths. See LoadString. We use size_t there
just to handle long strings in 16-bit platforms; no one is really going to save a string longer than 2Gb in a precompiled chunk, but it's quite possible they want to use a string longer than 64k in a 16-bit platform
that can address 32-bits (eg, old segmented models in DOS).

If your ints are 32-bit, you can most probably use int instead of size_t
when dumping.