Re: Publishing with Lzip

["Ludovic Courtès" <ludo@gnu.org>]

Hi!

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

>> I’d also recommend to re-read the API doc in the headers or whatever.
>> IME these APIs are very tricky to use and one has to pay attention to
>> every small detail.
>
> I read the manual too many times.  The headers are not documented.  The examples
> don't tell us more about the API.
>
> I might be too inexperienced in the area, so maybe you or someone else could
> have a look at the manual.
>
> Else we could contact the maintainer and ask directly :D

Well, we’ll see!

>> According to the C standard an enum is an ‘int’.  So mapping them is
>> just a matter of producing/consuming ints.  The values of the enum start
>> from 0 and are incremented by 1 from then on, unless specific values are
>> provided.
>
> My question was whether it's possible to have the mapping done "symbolically."
> In C, you would match error values again the symbols of the enum, not against
> the number.  So if we map the error numbers manually in Guile, it would break
> whenever the API updates the enum.
>
> Maybe I'm just being overly picky here :p

Indeed.  :-)

The funny thing with the FFI is that it gives “a whole bunch of new
flexibility” to shoot yourself in the foot.  So for enums, while you
could do something fancy to extract the values from the headers (using
nyacc’s ffi-helper, or by running the C compiler at macro-expansion
time), what I would recommend is to just grab them once and for all.
:-)

In practice that works well: C library writers have an incentive to keep
ABI compatibility, so they’ll rarely change enum values.  This is
especially true for a library like this one whose API is probably set in
stone given that the scope of its functionality is well-defined.  We did
that for example in Guile-Gcrypt and Guile-Git and everything works
fine.

That also means that it’s a good idea to have unit tests that exercise
all the bindings.

HTH!

Ludo’.