[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua Cross Compiler
- From: Asko Kauppi <askok@...>
- Date: Fri, 4 Apr 2008 14:21:46 +0300
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
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
*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
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
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
to save a string longer than 2Gb in a precompiled chunk, but it's
possible they want to use a string longer than 64k in a 16-bit
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