Preallocating lua string before pushing them on the stack (prevent double alloc / memcpy)

[Cuero Bugot <cbugot@...>]

Hi all,

Several time already I bumped into the fact that the C Lua API does not provide a mechanism for preallocating the strings before pushing them on the stack.
I know that there is the very usefull luaL_Buffer tool, that almost solve all string preallocation problems. But it has three (minimal maybe) drawbacks for my use case:
1) The luaL_Buffer struct statically contains the temporary buffer (size : LUAL_BUFFERSIZE), which may be a prb if you do not want to consume the C stack too fast (on low end embedded system it matters)
2) The maximum size that you can copy at a time (with luaL_prepbuffer) is limited to LUAL_BUFFERSIZE. It can be a prb when you cannot force an external C reader to limit what it reads to some size (yes some people did design crappy API ;-) )
3) Whatever happens it will do a memcpy to copy the temp buffer into a new allocated Lua string object

I have a proposal to circumvent those drawbacks. The idea would be to add 2 APIs:
      char *luaL_prepstring (lua_State *L, size_t len);
	void lua_pushprepstring (lua_State *L, char *prepstring);

The 1st one would actually allocate an "empty" Lua String object (only allocation, no hash, no registering, etc.)
The 2nd one would push the allocated string on the stack. To do so it would do it the same way as currently: compute the hash, see if the string is already registered (free the prep string buffer in that case), and if not registered do it (use the prep string buffer to store the actual Lua object)
Note: instead of passing a char* (which may be error prone), the function could use a Typedef object (by reference as a third argument)

I looked at the Lua code itself, and I found out that this would be actually pretty easy to implement. The idea would be to give
	TString *luaS_newlstr (lua_State *L, const char *str, size_t l);
a 4th argument: TString *ts.
When this 4th argument is set to nul then luaS_newlstr would have exactly the same behavior as it does currently, when this 4th argument is non nil then it means that the struct is already allocated and it uses it instead of allocating a new string.


To conclude: this would be indeed a small optimization (but with a small code modification). This email is rather there to "take the temperature" than for desperately asking for an evolution of the Lua C API.
I did not write the code (yet), but if somebody find this not stupid enough I can deliver it.