 |
lua-l archive |
|
|
||
|
On Friday, August 16, 2002, at 10:40 AM, John Belmonte wrote:
So what you're suggesting is that every app or library you run on your embedded system create its own mini-printf as needed. If you have enough libraries doing that you'll go over the size of the standard C's implementation anyway. Plus there is the wasted human effort.
I thought he was suggesting that each app didn't have to do that because Lua already included it's own limited, custom printf. The authors of Lua may not want to adopt the syntax and complexity of the standard C formatting notation --- it is quite complex; preferring to have a simpler printf that actually will have it's functionality available in embedded systems that use the standard Lua source.
If you don't buy that, then consider that if your apps and libraries truly don't require the full printf, then all you need do is replace the standard C's implementation according to your constraints (and cover everything you run on your system in one swipe). With this, the person that needs the special case is the one that does the special work, and everyone else gets the generality afforded by the C library.-John John Passaniti wrote:If *printf is already linked in elsewhere by Lua, I guess I don't have abig problem with this. The cost of the format interpreter is already there. But if this is the only place where *printf is used, then I would prefer that Lua *not* use *printf. Those of us who work with embedded systems typically have memoryconstraints we have to worry about, and the core routine that implementsthe *printf family of functions can be a surprisingly huge-- both in terms of code, and in some implementations stack and RAM usage. For those using Lua on desktop systems, with gobs of virtualized memory, none of this matters. For those who are trying to fit inside limited address spaces, we cringe anytime anyone wants to link in something large.-- http:// i . /