Re: [PATCH v3 5/6] libgit: add higher-level libgit crate

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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).








[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux