Re: [Tinycc-devel] tcc_relocate() and tcc_relocate_ex()

[Sean Conner]

It was thus said that the Great grischka once stated:
> Sean Conner wrote:
> >It was thus said that the Great Thomas Preud'homme once stated:
> >>Indeed, I agree the commit message is not very verbose as to the reason 
> >>of the change. For people interested, the said commit is 
> >>8bbde91f62291cb0383c2406ae6123be903c944b
> >>
> >>That said, the change of API seems clearly intentional, as if 0.9.25's 
> >>behavior had a fundamental problem. Thus, I'm reluctant to apply your 
> >>patch right now. Grishka, could you tell us the context behind this 
> >>revert?
> >
> >  I don't think 0.9.25 had problems, since currently, tcc_relocate() calls
> >tcc_relocate_ex() (if HAVE_SELINUX is not defined).  The only thing I can
> >think of is that a significant amount of code expected the 0.9.24 version 
> >of
> >tcc_relocate() and it was easier to change 0.9.25 than to change the
> >existing code, but that's just conjecture on my part.
> >
> >  -spc (I did try to keep the patch as simple and isloated as possible)
> >
> 
> The reason to revert tcc_relocate was to make the libtcc_test example
> look as simple as it was before.
> 
> The reason for not yet to export tcc_relocate_ex was that I wanted
> to know if anyone would actually care for the 'extended' version,
> i.e. to wait for someone to complain. :-)

  Well, it looks like it took a few years, but yes, I build code around the
0.9.25 version of tcc_relocate().  

> As to the patch I think that
>     +    s1->runtime_mem = NULL;
> would break tcc_relocate and I don't see why you need it.

  I did that so that the call to tcc_delete() wouldn't crash when it tried
to free s->runtime_mem that might contain a garbage value (since
tcc_relocate_ex() would never set that field).  Good thing too, because
tcc_new() *might not* be initializing NULL pointers correctly [1].

> If you agree with I will push a patch to declare tcc_relocate_ex
> as LIBTCCAPI and nothing else.

  Well, I would like to see tcc_relocate_ex() promoted, so I agree to that.

  -spc (But I would feel safer with the NULL pointer assignment ... )

[1]     Depending upon how pedantic you want to be, doing:

                char *p;
                memset(&p,0,sizeof(p));

        does not guarantee that p will be a valid NULL pointer.  In ANSI C,
        a zero value in a pointer context, like:

                char *p = 0;

        will convert the '0' to a valid NULL pointer for the platform, which
        need not be an actual 0 value (it could very well be a bit pattern
        of alternating ones and zeros for some obscure Elbonia [4] CPU).  A
        lot of popular architectures in use today *do* use all zero bits in
        a pointer as a valid NULL pointer, so mallocz() [2] will initialize
        pointers to a valid NULL value, but not ANSI C doesn't mandate that.

        Now, given the systems that TCC builds code for, this might not be
        an issue. [3]

[2]     The standard ANSI C function calloc() does this---why not use it?

[3]     Except for the odd Elbonian [4] trying to build a cross-compiler for
        x86 platforms.

[4]     http://en.wikipedia.org/wiki/Dilbert#Elbonia