2

Given that the LuaL_Buffer object: "During its normal operation, a string buffer uses a variable number of stack slots", I don't understand how two luaL_Buffer objects can be used at the same time. Will they each assume the state of the stack is as they require? In other words, one buffer might put something on the top of the stack and expect it to be there in some future call, while the same being true for another buffer? Is it not possible to work with two LuaL_Buffers at the same time?

Here is an example of some operation that requires two buffers at the same time. It seems to work for small tests, but don't know if it will stand up in production.

int res;
char *p;
size_t dlen;
struct luaL_Buffer src;
struct luaL_Buffer dst;

luaL_buffinit(L, &src);
luaL_buffinit(L, &dst);
luaL_addvalue(&src);
// .. grow/mod the src buffer in various ways
p = luaL_prepbuffsize(&dst, dlen);
res = my_uncompress((Byte *)(src.b), src.n, (Byte *)p, &dlen);
luaL_addsize(&dst, dlen);
// .. do things to the dst buffer ..

where my_uncompress is wrapper to a zlib method

hjpotter92
  • 78,589
  • 36
  • 144
  • 183
Paul
  • 2,973
  • 6
  • 31
  • 40

1 Answers1

2

You generally can't use two luaL_Buffers at the same time. Just as you can't use mess around with the stack while in the middle of a function that assumes you don't mess with the stack.

You can use two luaL_Buffers, but only if you fully nest the calls. That is, the first buffer you prepped cannot be modified as long as the second buffer you prepped hasn't been finished with luaL_pushresult.

The absolute best you can do is use lua_newthread to create a new thread stack and put each buffer into its own thread. However, this is a terrible abuse of the API, and I wouldn't suggest it.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
  • Yes, the example was not the best. Trimmed down, the sample code doesn't need buffers at all. (`dst` could be a byte array as well) However, in full context it makes sense to use them. This leaves me wondering if there are useful idioms for ensuring the "nestedness" of the buffer usage. Like a "dirty" flag on an uncommitted db call. Or maybe there is a way to get an independent stack for each buffer. – Paul Jul 23 '12 at 16:48
  • 1
    @Paul: Ultimately, C isn't a safe language, so C APIs aren't going to save you from doing stupid things. You have to take responsibility for using these low-level constructs like `luaL_Buffer` and such. – Nicol Bolas Jul 23 '12 at 16:53