lua-users home
lua-l archive

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


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