Re: Making Lua 5.2 even easier to port
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Making Lua 5.2 even easier to port
- From: Doug Rogers <doug@...>
- Date: 2010年1月17日 01:49:08 -0500
David Burgess wrote:
This post is about begging for some small changes in 5.2.
...
I have ported Lua to a lot of different platforms and new platforms keep
appearing. On embedded systems it is not uncommon for there only to be a
subset of the standard C runtime library and one can usually bet on not
having stdio. ...
#define luai_puterrstring(s) fputs((s), stderr)
#define luai_getconsolestring(b,l) fgets((b), sizeof(char), (l), stderr)
+1
In lauxlib.c lines 497 thru 568 luaL_loadfile() et al
This seems to be an always change it piece of code which is not always
easy due to the ungetc(). I welcome suggestions for removing the stdio
dependency in this code.
Yes, this one takes special code when porting to stdio-impaired systems.
Note that it appears in liolib.c, too. When I'm using a UART or
something, I just put in a multi-character buffer (usually f is always
stdin). But to do the job right, it has to handle end-of-file properly
(as it is used in liolib.c). Basically, the functionality of ungetc()
would need to be provided by Lua just to make it easier on us embedded
porters - possibly using some kind of abstraction of the FILE handle.
Unless a particularly elegant solution can be found, I don't think it's
worth it. We will know best how to handle it in each location.
and in loadlib.c line ~388 (my pet hate)
static int readable (const char *filename) {
This could become luai_readable() in luaconf.h.
You know, I don't even remember this being a problem for me. In the most
stdio-impaired system to which I ported Lua, I just provided a full set
of fxxx() functions that did nothing - fopen() always returned NULL, for
example.
Good suggestions, all.
Doug