[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] Question about in-memory compilation target
From: |
Sean Conner |
Subject: |
Re: [Tinycc-devel] Question about in-memory compilation target |
Date: |
Thu, 8 Feb 2024 05:22:01 -0500 |
User-agent: |
Mutt/1.4.1i |
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