Hi,
On Mon, 27 Aug 2012, grischka wrote:
Can you at least commit the change that makes tcc_relocate_ex() global?
Yes, perhaps at least. You wrote:
... but fixing my code to match the current definition
of tcc_relocate() was out of the question (the surrounding code manages the
lifetime of both the TCCState and the resulting executable code compiled
into memory).
I'd actually like to know some details why you can't just use
tcc_relocate()?
So Sean meanwhile answered this extensively, but I'd actually ask back why
the answer to this question matters? The _ex function exposes a strict
superset of possibilities of the non _ex variant, that much is very
obvious, so asking why the more limited API isn't enough for everyone,
when it once was more capable and actually used in that extended fashion
seems patronizing to me. There's clearly a use for the extended API
(clearly in the sense, it once worked, now with the limited API it
doesn't, and I don't see how to work around the limitation with the
current API), and exporting the relevant, though renamed symbol, isn't
affecting the future of libtcc stability, insofar it exists (which it
doesn't), at all.
So, while the complaint about the leak is correct, the conservatism about
exporting one internal function (whose functionality once was available as
an exported function that was removed from the API) is hypocritic at best.
Sorry for that assessment. IOW: I don't understand your reservations.
To make it short: just export the damn thing. It makes sense.
Admittedly we know little about how people actually use
the libtcc API.
Well, we now know a little bit more.
Ciao,
Michael.
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel