You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support custom reprs, and constants in range bounds #8
There is also that #[repr(libc::c_int)] is not possible but #[repr(transparent)] should allow that without problem not need to use #[repr(libc::c_int)]directly for structure. I don't think it's possible for enum rust-lang/rust#68122.
This is just a feedback of my personal use case, I totally agree with closing this.
The trouble with allowing custom type reprs is that bounded-integer doesn't know their signedness and size. Signedness is used to determine whether abs, checked_abs, Neg and checked_neg should be generated, and size is used to generate the From<{bounded type}> for {larger types}.
I think the best option is to special-case c_* types for bounded integers, and support arbitrary const expressions inside bound ranges for structs instead of requiring a value evaluatable by the macro.
And I just encountered another problem - automatic repr detection does not work if the macro doesn't know the value of each range bound when it runs (this is the case if we allow constants in range bounds).
I will leave this issue open because someone might potentially come along with a better solution in the future, but for now I don't think I can solve this.
Activity
Kestrer commentedon Mar 20, 2021
The trouble with allowing custom type reprs is that
bounded-integerdoesn't know their signedness and size. Signedness is used to determine whetherabs,checked_abs,Negandchecked_negshould be generated, and size is used to generate theFrom<{bounded type}> for {larger types}.I think the best option is to special-case
c_*types for bounded integers, and support arbitraryconstexpressions inside bound ranges for structs instead of requiring a value evaluatable by the macro.Stargateur commentedon Mar 20, 2021
I don't think it's a good idea, do a specialization just for the libc add a lot of work for this crate.
I think this need a general solution or just don't do it. After all I don't think there will be ever a OS where
c_intis not ai32:p.I'm fine with:
Kestrer commentedon Mar 20, 2021
And I just encountered another problem - automatic
reprdetection does not work if the macro doesn't know the value of each range bound when it runs (this is the case if we allow constants in range bounds).I will leave this issue open because someone might potentially come along with a better solution in the future, but for now I don't think I can solve this.
[-]Feedback: Problem with limitation of the macro[/-][+]Support custom reprs and constants in range bounds[/+][-]Support custom reprs and constants in range bounds[/-][+]Support custom reprs, and constants in range bounds[/+]Kestrer commentedon Aug 8, 2025
The new
unsafe_api!macro should cover this use-case. For example:The second one can now be handled by the macro directly: