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 _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel