On 2024.09.18 09:34, Junio C Hamano wrote:
> Josh Steadmon <steadmon@xxxxxxxxxx> writes:
>
> > We want to namespace types as well as functions, as Phillip pointed out
> > in 47b18fa4-f01b-4f42-8d04-9e145515ccc1@xxxxxxxxx.
> >
> > Is there a reason why we need the shim struct from your
> > xmqqcylcpnah.fsf@gitster.g and can't just cast directly like so:
> > ...
> > int libgit_configset_get_string(struct libgit_config_set *cs, const char *key, char **dest)
> > {
> > - return git_configset_get_string(cs, key, dest);
> > + return git_configset_get_string((struct config_set *) cs, key, dest);
> > }
>
> Not at all. I just didn't see your intentions in the patch if all
> you wanted to do was merely to flip names, or wanted to leave the
> possibility to allow the wrapped ones to optionally have different
> shape (e.g. for bookkeeping purposes for either the host environment
> or the shim layer). If it is merely "we do not want to expose these
> names but we want bit-for-bit identical data", then you do not need
> extra logic at all---the casts would be suffficient[*].
>
> PS. I am not feeling well today, so please expect delayed and/or
> sparse responses.
>
>
> [Footnote]
>
> * Building objects that go to libgit.a, partially linking them to
> resolve internal references, and then rewriting the symbol table
> of the resulting relocatable object file to expose only the entry
> points and data you want to show to the rust world to whatever
> names you want, would be a less gross solution, I would imagine.
> You only then need to write a (fake) public_symbol_export.h file
> that will never has to be seen on the C side, but to be seen as
> the header to describe that C library to the rust side (and
> obviously you do not need public_symbol_export.c file only to keep
> these casts).
I don't think I'll have time to experiment with this approach for V4,
but I'll put it on our list of future work. For now I'm just keeping
public_symbol_export.{c,h} as-is and casting to avoid exposing the
unmangled struct name.
