lua-users home
lua-l archive

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


On 01/02/2008, Thomas Harning <harningt@gmail.com> wrote:
> Paul Moore wrote:
> > The biggest issue I have is that converting char <-> wchar_t requires
> > memory buffers for the conversion. I can obtain these in a number of
> > ways (the lua allocator, creating userdata objects, etc) but I need to
> > manage the lifetime of the buffers
> One of the API's in Lua that I think might solve at least the wchar_t ->
> char problem is the luaL_Buffer setup [1].
[...]
> I'd hope that some sort of _convert_ API exists like that...

I'm using the Win32 conversion functions. These take the input, an
output buffer, and the buffer size. If the output buffer isn't big
enough, they give an error. If you call with a null output buffer,
they return the required size. It's fine for converting arbitrary
strings, but it doesn't really support incremental conversion.

Having looked at the documentation, and done some thinking, the main
problem I have is that luaL_prepbuffer returns an address to a space
of size LUAL_BUFFERSIZE, which although likely to be large enough, is
still fixed in size. When using the Win32 APIs to convert wide
characters, I need to allocate a buffer of arbitrary size. (OK, 99% of
the time, LUAL_BUFFERSIZE will be big enough, so I'm being obsessive
here :-))

As I'm also potentially raising errors, using lua_Alloc gets messy
(for example, if the final lua_pushstring fails for some reason, I
don't get a chance to free my buffer).

So it looks like I have 2 reasonable choices:

- Use luaL_Buffer and disallow strings over LUAL_BUFFERSIZE.
- Use lua_newuserdata to allocate a memory block on the stack which is
managed by gc.

I could use a hybrid, using luaL_Buffer if LUAL_BUFFERSIZE is OK,
otherwise allocate a userdata. That is probably overkill, though.

Thanks for the suggestions. I'll probably go with the userdata option,
just because I hate code with arbitrary limits.

Paul.