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 }}
This repository has been archived by the owner on Aug 6, 2023. It is now read-only.
I've using afl.rs to fuzz this crate. And I've found several API may panic due to arithmetic overflow.
There are four APIs we find may panic. We just download tui.rs from this respository and add it as a dependency to our fuzzing target. The codes to replay this panics are
Just come across the second of these in 'normal', non-fuzzing usage trying to find the intersection of two rectangles that don't intersect. I'm happy to submit a PR for this but unsure of preferred approach.
Could either use saturating_sub and return an intersection with 0 height/width, or make the return type an Option<Rect>. The second option feels more correct as there is no intersection to return but it is a public API so would be a breaking change. It currently has no references within the library but there's no way of knowing how widely this is used.
I haven't worked on the project in a bit, but as a point of reference, when we hit a similar problem a long while ago we used saturating adds and subtracts #283
I've using afl.rs to fuzz this crate. And I've found several API may panic due to arithmetic overflow.
There are four APIs we find may panic. We just download tui.rs from this respository and add it as a dependency to our fuzzing target. The codes to replay this panics are
we also put these code on first, second, third, fourth.
The bug report is
I hope you can check if these are real bugs need to be fixed. Thanks a lot.
The text was updated successfully, but these errors were encountered: