[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: Compiled chunk loading cross platform
- From: Chris Chapman <Chris.chapman@...>
- Date: Thu, 29 Jan 2004 16:34:37 -0000
The
file is read in binary mode, even when reading text files, as the standard C
library file IO isn't available on PS2. The NULL termination is definitely
necessary for reading text files, as they don't have any implicit terminator,
but you are absolutely right - I was using strlen(szBuffer). Doh! The PS2 reading
code/lua_dobuffer call should use the exact size of the file on disk + 1
byte for the NULL terminator. My own fault for looking for a more complex
problem than the one which actually existed.
Thanks for the help
C
> I'm having a
strange problem with loading my compiled chunks on a
> different platform.
<SNIP>
> What I'd
like to know is whether there are any structure packing settings,
> alignment issues, or other general things to be
aware of when loading
> compiled lua scripts.
The main thing to be aware of is line-end conversion on platforms
which
distinguish between text and binary
files. If you are using standard C
libraries
to read a file of byte-code and your standard C library cares
about line-endings, you must open in mode "rb" to avoid
data corruption.
> My PS2 loading code
is as simple as loading the script
> into a buffer, concatenating a NULL
character to the end of it (to make sure
> text buffers are NULL
terminated), and passing that buffer off to
> lua_dobuffer.
The NUL termination is unnecessary, and the compiled
script may have
internal NULs. What does your
call to lua_dobuffer
look like? If it is
lua_dobuffer(L, buff, strlen(buff), "name");
then buff's length will be computed incorrectly (since
strlen
stops at the first NUL) and Lua will
undoubtedly report a premature
end of
file.
> Also, how is Lua detecting the
end of file? I don't see any
> obvious record of the file size internal
to the format, I don't pass the
> size to lua_dobuffer, and I don't see
an obvious EOF character, so I assume
> some parse logic determines when
there is no more data to read...?
It is
very standard marshalling code. The demarshaller knows how long
scalar datatypes are (and this information is coded into
the header to
ensure that the sizes are
compatible); compound datatypes like strings
and tables are prefixed with their element counts. The marshalled
script
contains a single root object which is
a compound object; the demarshaller
recursively reads this object and all of its subobjects until it is
done.
If it runs out of data before it
finishes, it reports premature end of file.
