[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: How far should one go preventing potential memory leaks?
- From: <benjamin.steinwender@...>
- Date: Mon, 9 May 2016 08:20:41 +0000
const char *lua_pushfstring (lua_State *L, const char *fmt, ...);
[-0, +1, m]
no need for custom allocation here ...
-Benjamin
-----Original Message-----
From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On Behalf Of Marc Balmer
Sent: Monday, May 09, 2016 9:37 AM
To: Lua mailing list
Subject: How far should one go preventing potential memory leaks?
I would like to open a discussion on best practices for preventing memory leaks in C programs using the Lua API.
Consider the following code snippet:
char *s = malloc(32);
snprintf(s, 32, "bumblebee");
lua_pushstring(L, s);
free(s);
lua_pushstring() could raise an error (e.g. under memory pressure) and then the subsequent free(s) would not be called, leaking the memory.
One could use lua_newuserdata() instead of malloc, but this works only if the memory is allocated by our own code, it does not work where the memory is allocated e.g. by a third party library.
So a possible way could be to create a metatable containing a __gc method, then allocating a small userdata value containging only a pointer to the allocated data. The __gc method could then free the memory, even if lua_pushstring() fails.
Is it worth the effort? How do others (you) handle this kind of possible errors?
My personal take on this is, btw: I don't care as I long as I don't reference NULL pointers. If we are under memory pressure and functions like lua_pushstring() are starting to fail, we will be in much deeper trouble anyway soon... ymmv, opinions very welcome.
- mb