Is there a reason for dropping type safety in some of the API calls?

[gantzm]

Is your feature request related to a problem?

In the file af.h, we see the following:

typedef void *ezb_af_ep_desc_t;
typedef void *ezb_af_device_desc_t;

I understand there might be a need to hide internal data structures but this is not a type safe way of doing that. With this type of construct the compiler can't warn us about misused data.

Describe the solution you'd like.

It seems much more safe to write the descriptions as:

typedef struct ezb_af_ep_desc_s {} *ezb_af_ep_desc_t;
typedef struct ezb_af_device_desc_s {} *ezb_af_device_desc_t;

This way if we make a mistake in our code the compiler can at least tell us we've done something wrong.

Describe alternatives you've considered.

I would also consider having the full structure definitions, but that may not be possible.

Additional context.

No response

Edit: Cleaned up a few typos.

[finalyards]

In my work for making a Rust bridge for the 2.0, I noticed that the ezb_app_signal_get_type() provides ezb_app_signal_type_t (which is uint16_t). Could the return type be ezb_app_signal_type_e, directly?

[lpy4105]

ezb_app_signal_type_t is exactly the type returned by ezb_app_signal_get_type(), and ezb_app_signal_type_e is just providing the value of this type.