That is nice, I wish I had thought of it.
Any thoughts about my suggestion from a few days back that tcc_relocate()
could be dropped from libtcc.h, and instead be automatically called on the
first
call to tcc_get_symbol()?
On Tue, Feb 13, 2024 at 4:15 PM grischka wrote:
> On 11.02.2024 11:08,
On 11.02.2024 11:08, draco via Tinycc-devel wrote:
You're right, I didn't verify closely, but the ABI is still intact. Sorry...
To be nice I've made tcc_relocate() abort with a notice
when it's called with the former two-step method ;)
-- gr
Am 10.02.24 um 22:12 schrieb Eric Raible:
>
You're right, I didn't verify closely, but the ABI is still intact. Sorry...
Am 10.02.24 um 22:12 schrieb Eric Raible:
> This means, that not only the public API changes, but also the
> libtcc.dll/so ABI, making all programs using libtcc crash without warning.
>
> Is this intended?
>
> Michael
I've just taken a closer look at libtcc.h. Now, I realize that this is
radical,
but for the sake of discussion... if we're willing to break compatibility
it seems
to me that just one new API:
/* add option as on a comment line (multiple supported) */
LIBTCCAPI int tcc_argv_add(TCCState *s, const
> This means, that not only the public API changes, but also the
> libtcc.dll/so ABI, making all programs using libtcc crash without warning.
>
> Is this intended?
>
> Michael
I just tried it. It looks like only programs that _don't_ use
TCC_RELOCATE_AUTO would be affected (at least on my
This means, that not only the public API changes, but also the
libtcc.dll/so ABI, making all programs using libtcc crash without warning.
Is this intended?
Michael
Ok, I like it to remove stuff:
https://repo.or.cz/tinycc.git/blob/b671fc0594625eb5ac147ec83be6d0c1fc1a6ad5:/libtcc.h
On 09.02.2024 01:44, Eric Raible wrote:
> Then, instead of adding a new API to support the
> "run without state"
> option better (as you suggest), we could just as well remove that
> option entirely, and have a simpler and more "lovely" API then ...
>
> What do you think?
>
I think
Sean Conner wrote in
<20240208102201.gb22...@brevard.conman.org>:
|It was thus said that the Great grischka via Tinycc-devel once stated:
|> On 07.02.2024 09:38, Eric Raible wrote:
...
| Lua contains a way to set a custom realloc() function (via
|lua_newstate()), thus allowing someone who
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
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
Nice!
Thank you... that's exactly what I needed.
Brad
On 2024-01-19 08:09, grischka via Tinycc-devel wrote:
On 15.01.2024 00:51, Brad Robinson via Tinycc-devel wrote:
Questions:
1. Is it possible to keep, use and then release the compiled code
after the initial compiler instance has
On 15.01.2024 00:51, Brad Robinson via Tinycc-devel wrote:
Questions:
1. Is it possible to keep, use and then release the compiled code after the
initial compiler instance has been deleted
FYI below some version of libtcc_test.c to run without state.
Note the LoadDll is needed only when the
Hi Michael,
Thanks, yep that's what I found too except I think that code doesn't run
if you relocate to a user supplied block of memory (instead of the tcc
managed one). My problem was that tcc_run_free() wasn't run on my
allocated code memory when I freed it - leaving pages that have been
Is it possible to keep, use and then release the compiled code after
the initial compiler instance has been deleted (ie: after tcc_delete).
Actually I strugled with the same problem and found a partial solution:
If you look up the code in libtcc.c, in function tcc_delete is the line
14 matches
Mail list logo
