lua-users home
lua-l archive

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

Thanks for the support. I guess I am just arguing for the stuff that you know you will have to change to put put in one place, Lua mostly has this. What I have listed are the exceptions (that I find(.

On 17/1/2010 5:49 PM, Doug Rogers wrote:
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)


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

Good suggestions, all.