Re: [Tinycc-devel] libtcc API v.s. global state v.s. tcc state

[grischka]

From: "egodust":
> 1. tcc_new() MUST be matched by a tcc_delete() that share the same
> sections, i.e. no mixing of different states, only ONE state is
> allowed to exist at a time because of global copies.

No, that does not follow necessarily. It only means that
only one state can have global copies. But there can be
other states too, just not with global copies.

> tcc_delete() does:
> 
>  free_section(symtab_section->hash);

You can make free_section delete the hash link automatically.
Then this is not needed.

> So because of globals, tcc_new() and tcc_delete() must MATCH, you
> can't call tcc_delete() afterwards, because tcc_new() overrides
> globals.

No, that is not how it is. True, tcc_new() overrides globals, but 
that only means that you cannot do compilation with an old state 
anymore.  But you still can run the code in it.  It's not perfect,
but it is equal to your solution.  I mean, it *IS* your solution,
just that TCCBinary is TCCState actually.

> Sure, but libtcc passes around global data that is shared with ONE
> state. I only wanted the binary to stay in memory, if you don't like
> the APIs (i.e. the extra free), feel free to suggest something else :)
> 
> I just didn't want to complicate the design.

But you did exactly that by adding extra functions to the libtcc 
interface ;)

Well, I need to suggest something.  So, maybe I'd move the bits in 
tcc_delete, that mess with globals, out from tcc_delete into another 
function.  Then that function (name it "tcc_cleanup") can be called 
from tcc_new instead.  How is this?

To make it all balanced you can have a state counter. 

tcc_new() 
{
   if (state_count++) 
        tcc_cleanup();
   ...

tcc_delete()
{
    if (0 == --state_count)
        tcc_cleanup();
    ...
   
--- grischka