*h++=(char)LUAC_FORMAT;
Irrelevant
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:
http://lua-users.org/lists/lua-l/2006-02/msg00507.html
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).