chore(core): don't implement `Lerp` & `InvLerp` for 32-bit integers
What the developer wrote
Authored by Roman Zeyde
chore(core): don't implement `Lerp` & `InvLerp` for 32-bit integers
Since `f32::from()` doesn't support u32/i32.
[no changelog]
What changed, and why it matters
This is a routine code cleanup. The developer removed support for 32-bit integer types from two internal helper functions (Lerp and InvLerp) used for calculating intermediate values in the user interface. The reason given is that the underlying conversion function does not support 32-bit integers. The change only affects which numeric types can use these helpers and does not fix or introduce any security issue.
No security action needed. Treat as normal maintenance.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The commit removes macro-generated trait implementations of Lerp and InvLerp for i32 and u32 in core/embed/rust/src/ui/lerp.rs, leaving only i16, u8, u16, and f32. The commit message states this is because f32::from() does not support u32/i32. Unit tests are updated to use the remaining 16-bit types. There is no change to logic, bounds checking, or memory handling.
Changed components
core/embed/rust/src/ui/lerp.rsInspect captured patch +9 / −11
diff --git a/core/embed/rust/src/ui/lerp.rs b/core/embed/rust/src/ui/lerp.rs
index 1f91efd2..ea79b958 100644
--- a/core/embed/rust/src/ui/lerp.rs
+++ b/core/embed/rust/src/ui/lerp.rs
@@ -66,10 +66,8 @@ macro_rules! impl_lerp_for_unsigned {
}
impl_lerp_for_signed!(i16);
-impl_lerp_for_signed!(i32);
impl_lerp_for_unsigned!(u8);
impl_lerp_for_unsigned!(u16);
-impl_lerp_for_unsigned!(u32);
impl_lerp_for_signed!(f32);
@@ -79,18 +77,18 @@ mod tests {
#[test]
fn lerp_for_int_and_uint() {
- assert_eq!(i32::lerp(0, 8, 0.5), 4);
- assert_eq!(i32::lerp(0, 8, -1.0), -8);
- assert_eq!(i32::lerp(8, 0, 0.5), 4);
- assert_eq!(u32::lerp(0, 8, 0.5), 4);
- assert_eq!(u32::lerp(8, 0, -1.0), 16);
+ assert_eq!(i16::lerp(0, 8, 0.5), 4);
+ assert_eq!(i16::lerp(0, 8, -1.0), -8);
+ assert_eq!(i16::lerp(8, 0, 0.5), 4);
+ assert_eq!(u16::lerp(0, 8, 0.5), 4);
+ assert_eq!(u16::lerp(8, 0, -1.0), 16);
}
#[test]
fn inv_lerp_for_int_and_uint() {
- assert!((i32::inv_lerp(0, 8, 4) - 0.5).abs() < f32::EPSILON);
- assert!((i32::inv_lerp(0, 8, -8) - -1.0).abs() < f32::EPSILON);
- assert!((i32::inv_lerp(8, 0, 4) - 0.5).abs() < f32::EPSILON);
- assert!((u32::inv_lerp(0, 8, 4) - 0.5).abs() < f32::EPSILON);
+ assert!((i16::inv_lerp(0, 8, 4) - 0.5).abs() < f32::EPSILON);
+ assert!((i16::inv_lerp(0, 8, -8) - -1.0).abs() < f32::EPSILON);
+ assert!((i16::inv_lerp(8, 0, 4) - 0.5).abs() < f32::EPSILON);
+ assert!((u16::inv_lerp(0, 8, 4) - 0.5).abs() < f32::EPSILON);
}
}
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.