Re: libgpiod: rust bindings and bindgen issue with C enums

[Miguel Ojeda <miguel.ojeda.sandonis@xxxxxxxxx>]

On Thu, Nov 24, 2022 at 3:58 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
>
> The possibility for error can arise from running against a later
> libgpiod that has additional values for the enum that these bindings are
> obviously unaware of. e.g. the hte event clock recently added.  If you
> had bindings built prior to that addition there is no Rust variant
> in the event clock enum for that to map to.

If using older bindings against newer libraries is intended to be
supported (and not just the other way around), then I would expect at
least some of the enums to be stable (i.e. exhaustive), no? Say,
`Direction` or `EdgeKind`. Are new variants expected in those (before
a major 2.0)?

And for those that aren't designed to be stable, `InvalidEnumValue` is
a bit misleading. It is just that it is unknown to the bindings (which
is more useful for users: "I should update my bindings"), or
"unexposed" (a term some bindings use when the value is still usable
even if opaque).

Now, the C++ side throws even for the clock mapping (and the exception
says "thrown when the core C library returns an invalid value"), which
to me it sounds like the C++ bindings are not intended to be used if
there is a mismatch. Thus Rust could panic too.

On the other hand, if the bindings are actually intended to be used
even when encountering unknown values, then I would say C++ shouldn't
throw, Rust shouldn't panic, and the enums should be marked as stable
or not as needed. Then, for the unstable ones, depending on whether an
unknown value can still be useful, it could be made an `Unknown`
variant on the particular `enum` (e.g. `EventClock::Unknown`) instead
of an error (the "unexposed" idea above).

Cheers,
Miguel