From: Josh Steadmon <steadmon@google.com>
Date: Mon, 07 Oct 2024 23:31:00 GMT
Subject: Re: [PATCH v3 5/6] libgit: add higher-level libgit crate
Message-ID: <paya2jpm67x3zfkwtttcjrkfe7ai63ez3scrtarbdolkcmxvbq@yant6zn63p4z>
In-Reply-To: <xmqqo74kj4ys.fsf@gitster.g>

On 2024.09.18 09:34, Junio C Hamano wrote:
> Josh Steadmon <steadmon@google.com> writes:
> 
> > We want to namespace types as well as functions, as Phillip pointed out
> > in 47b18fa4-f01b-4f42-8d04-9e145515ccc1@gmail.com.
> >
> > 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.