[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua 5.2 & SWIG compatibility problem
- From: Peter Cawley <lua@...>
- Date: Sat, 31 Dec 2011 15:57:32 +0000
On Sat, Dec 31, 2011 at 3:40 PM, Jeff Smith <spammealot1@live.co.uk> wrote:
> Thanks Roberto & Markus for the replies. As a quick workaround for the Swig
> issue I put an ugly macro into lauxlib.h
>
> #define lua_pushvalue(L,LUA_GLOBALSINDEX) lua_getglobal(L,"_G")
>
> This looks a valid fix to me, that meant I can now compile and link without
> errors.
Lua 5.2 defines a macro called lua_pushglobaltable, which would seem
to be the neater solution here, especially given that using "_G"
depends upon the base library having been initialised. Therefore
something like the following should allow for lua_pushglobaltable to
also be used around 5.1:
#ifndef lua_pushglobaltable
#define lua_pushglobaltable(L) lua_pushvalue(L, LUA_GLOBALSINDEX)
#endif
> Issue 1)
> I am running this 5.2 build on an oddball OS that hasnt got a realloc()
> function, so I had to write my own a while back. This new 5.2 showed up a
> weakness in my realloc implementation.
>
> 5.2 does something rather odd though that presumably 5.1 didnt. The first
> time a memory alloc occurs
>
> static void *l_alloc (void *ud, void *ptr, size_t osize, size_t nsize)
> The calling params are: ptr=NULL, but osize=8 nsize=368
>
> The oldsize param doesnt seem to really mean the old memory allocation block
> size any longer, its seems to be a LUA enum, 5,6,7,8 etc. I had used osize
> to decided if a memcpy was needed and was now causing a crash with 5.2. This
> was trivial to fix such that if ptr==NULL then it doesnt try and use osize
> now.
>
> The Lua code is kind of confusing here though, why an enum ?
Quoting myself (item 49 of http://www.corsix.org/content/look-lua-52-work3):
Slight change to how allocator functions are called - All Lua memory
(de/re)allocations are done through a user-supplied function (though
if luaL_newstate is used, that function is provided for you). This
hasn't changed. What has changed is how the allocator function is
called in order to perform an allocation. In 5.1, it would be called
with existing-size set to zero and existing-pointer set to NULL. In
5.2-work3, it is called with existing-pointer set to NULL and
existing-size set to LUA_TSTRING, LUA_TTABLE, LUA_TFUNCTION,
LUA_TUSERDATA, or LUA_TTHREAD if and only if one that type of object
is being allocated. This should allow for slightly better memory
allocation profiling.