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

[Sean Conner]

It was thus said that the Great grischka once stated:
> Jared Maddox wrote:
> >>but define a special value for 'ptr' to get behavior as of 0.9.24, as in:
> >>
> >>    /* Do all relocations. Needed before using tcc_get_symbol().
> >>       Possible values for ptr:
> >>         - TCC_RELOCATE_AUTO : Allocate memory internally
> >>         - NULL              : return required memory size for the step
> >>below
> >>         - memory address    : copy code into memory passed by the caller
> >>       returns -1 on error. */
> >>
> >>     LIBTCCAPI int tcc_relocate(TCCState *s1, void *ptr);
> >>     #define TCC_RELOCATE_AUTO (void*)-1
> >>
> >>Is this ugly?  Confusing?  0.9.26 isn't out yet so we can still decide.
> >>
> >>--- grischka
> >>
> >
> >If you're going to use that method, then I'd suggest this definition
> >of TCC_RELOCATE_AUTO:
> >#define TCC_RELOCATE_AUTO (void*)&tcc_relocate
> >
> >If I recall the C standard correctly, that will result on a value
> >that's unique from all other valid addresses even on Harvard
> >architectures (though porting TCC to one of those would be
> >"difficult"), thus ensuring that the new behavior can only be invoked
> >by accident if the calling code has a bug.
> >
> >It also makes it easy to not run into a conflict with anything else,
> >which could be relevant, since I half recall some architectures having
> >valid negative addresses for some reason..
> 
> Thanks, and so we conclude that even with most careful considerations
> unique can still be different to really unique, in practice.
> 
> In this case because &tcc_relocate in a libtcc.dll is resolved to
> the function itself, but in the client code is resolved to the
> function vector (on windows, with any of GCC, CL, TCC).
> 
> I dropped the minus and currently plan to go with
> 
>    #define TCC_RELOCATE_AUTO (void*)1
> 
> Better name or other suggestions still welcome.

  I do not like this idea, and here's why:  it produces a function that does
two different things depending upon one parameter:

        if TCC_RELOCATE_AUTO, it relocates the code somewhere for you

        if not TCC_RELOCATE_AUTO, it relocates the code in the memory given
        
        In both cases, it returns the number of bytes required to relocate
        the code.

  I can't stand functions that do more than one thing for no real good
reason.  And here, there's no real good reason to have a function that does
two things that are pretty much the opposite in scope (especially given that
tcc_relocate() calls tcc_relocate_ex() anyway!).  Also, with two functions
you avoid the crap of having to define TCC_RELOCATE_AUTO.  Also, the
simplest thing that would work with the least amount of code change is to
promote tcc_relocate_ex() to a public function (and possibly rename it to
something like tcc_relocate_here()).  I don't understand your relunctance to
do that.  Why add the excessive complication of TCC_RELOCATE_AUTO?

  -spc (At the very least, can you make tcc_relocate_ex() public?)