Cannot override integer type of constified enum module. about rust-bindgen HOT 4 OPEN

That's kind of intentional, because functions taking a node_kinds would need to accept a c-int (would break the ABI otherwise).

from rust-bindgen.

Same for structs containing it or what not. Thus, not clear it's a bug, would be rather dangerous to do as proposed. But please reopen if you disagree or I've gotten something wrong.

from rust-bindgen.

@emilio Sorry, my example had too little context.

I get your point but in this case, the real public type is node_kind (u16), not node_kinds (c_int), i.e.:

typedef uint16_t node_kind; 

// node_kinds exposes the valid values as a convenience,
// but the type itself is never used in the API
enum node_kinds {
  NODE_KIND_FOO = 1,
  // ... lotta kinds
};

typedef struct _node {
  node_kind kind; // uint16_t
  // ...
} node;

node* node_new_empty(node_kind kind);  // takes an uint16_t

There are many other places like this in the library, where:

• the API uses a specific integer type T (not c_int)
• an enum exposes the valid values for T as a convenience but the enum is never used as a type in the API

It gets even more annoying when #defined constants are involved since you have to juggle between c_int, u32 and u16 when it really should be just u16 everywhere.

Thus, not clear it's a bug,

Let's say it's a feature request then. 😉
I can open another issue (or update the OP) with a more accurate description of the use-case if you want.

would be rather dangerous to do as proposed.

Of course, if implemented it should definitely be opt-in.
There could also be a safeguard, i.e. fail to compile if the enum type is used as a function argument or return type?

But please reopen if you disagree or I've gotten something wrong.

Please note that regular users cannot reopen issues on this tracker.

from rust-bindgen.

reopening as per the above though I still think it'd be rather footgunny.

from rust-bindgen.