 |
lua-l archive |
|
|
||
|
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 alThis 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