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

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Tue, Nov 22, 2022 at 5:55 PM Miguel Ojeda
<miguel.ojeda.sandonis@xxxxxxxxx> wrote:
>
> On Tue, Nov 22, 2022 at 4:38 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
> >
> > ---
> > The expression that defines the value of an enumeration constant shall
> > be an integer constant expression that has a value representable as an
> > int.
> > ---
> >
> > and virtually all compilers store enum variables as signed integers,
>
> I don't think this is true. Both GCC and Clang seem to pick an
> unsigned one if possible (for the enum, not the constants), e.g.
> https://godbolt.org/z/6zjzMdP3T. I assume bindgen is using the one
> decided by clang.
>
> Note that the quote of the standard is a constraint, i.e. the values
> of the constants need to fit in an `int` (and the compiler is required
> to issue a diagnostic if they don't, under `-Wpedantic` in GCC/Clang).
>
> > As enums are naturally signed integers in the C world - can we somehow
> > make bindgen default to c_int for all enum types?
>
> This would be https://github.com/rust-lang/rust-bindgen/issues/1966,
> where it has been suggested as an option (as well as the fact that the
> constants are not being generated as `c_int`).
>

IIUC this is not done yet.

Viresh' code makes the assumption that all Enums are unsigned
integers. This would be easy to just convert to signed ints but having
both types supported seems impossible. For instance there's the
InvalidEnumValue error that takes an u32. There are more instances
where the enum's type matters.

What should I do in this case to accommodate two types for enums? I'm
bad at rust so I don't even know. In C++ I'd probably use templates if
I had this problem. So generics?

Bart