Re: [Tinycc-devel] TCC 0.9.25 is out

[grischka]

Jerome Vuarand wrote:
> 2009/5/20 grischka <address@hidden>:
> > Changes:
> >
> > - [...]
> > - tcc_relocate now copies code into user buffer
> > - [...]
>
> I'm in the process of updating a program that links to libtcc, and
> this change is quite annoying. It would have been nice to keep the old
> tcc_relocate as-is (put the code in a buffer related to the TCCState),
> and add another API to copy code in the user buffer.

We wanted to be nice with future users and not confuse them with two
very similar interfaces.

> On the other hand, assuming that's the way tcc is going to stay, it
> feels weird to pass the TCCState to tcc_get_symbol, while the returned
> address is in fact dependent on the buffer passed to tcc_relocate.
> Instead, it would feel more natural to copy the metadata in the user
> buffer, and pass it (without the TCCState) to tcc_get_symbol.

I don't know.  Maybe you have a point but it is hard to tell if we don't
know what you are trying to do and how the changed interface would cause
inconvenience (if any) with your specific case of usage.

> Finally the lifetime of the memory block passed to tcc_relocate is not
> clear to me. Can I delete the TCCState and still use symbols created
> by it as long as the memory block is valid ? 

The lifetime of the memory block is until you free it,  and as long as
it's valid, any addresses that point to it are valid too.

> Is freeing the block
> enough to free any resource (OS handles, temporary files, etc.) that
> is needed to support the relocated code ?

No.  The free() call in C does only one thing: free the memory. If there
are open OS handles stored in that memory, it is your problem.

> And last, but not the least, since tcc_relocate API changed, is there
> a define in the libtcc headers to detect which version is exposed ?

I don't think so.  Did you see any?  Maybe for next time.

--- grischka