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?)
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
