It was thus said that the Great grischka via Tinycc-devel once stated: > On 07.02.2024 09:38, Eric Raible wrote: > > The alternative is having to know about messy system-dependent details, > > which seems very much against the spirit of the (lovely) libtcc API. > > Well, if it's "lovely" then maybe because it's still small and > fairly easily to read. > > In any case, there is always a conflict between simplicity > and any new addition, even if they may come very convenient > in some case. > > Maybe you (or other people) could tell a bit more why now that > tcc_set_realloc() > can be useful enough that tcc should have it, more exactly? > > And if so, why then do we need > tcc_get_realloc() > too? Is that just an exercise about "setters" and "getters" or > is it really useful?
Lua contains a way to set a custom realloc() function (via lua_newstate()), thus allowing someone who is embedding Lua into an application to use a custom allocator, or even just restrict the amount of memory Lua can use. There is also a function in Lua to obtain the allocator function Lua is currently using (via lua_getallocf()). I checked, and back in 2012 when I created a Lua module around TCC [1] there was no way to set the TCC allocator to use the allocator from Lua. If someone went to the trouble of setting up a custom allocator for Lua, then any Lua module that might allocate memory should probably use it. I'll admit, my use case of TCC is a bit unusual, and my request to make tcc_relocate_ex() public after you made it private for some reason was met with over a month long argument about it. -spc [1] https://github.com/spc476/lua-conmanorg/blob/master/src/tcc.c _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
