Prevent out of bounds panics on range_to_human()

On range_to_human(), if the range is completely broken for some reason,
we might get a start = 0 and end = 0. In this case, then we would get
into an 'end - 1' computation for an 'usize', resulting in bad
arithmetics.

This can be avoided altogether if the 'start + 1' computation from the
start of the function not only results to be equal, but also larger than
'end'. This, of course, doesn't make much sense, and it's most probably
a bandaid; but it has been detected via fuzzy testing with wild
inputs. Hence, it's fine if this function doesn't return a coherent
string representation for deranged inputs.

Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>

1 files changed, 1 insertions, 1 deletions

diff --git a/lib/xixanta/src/assembler.rs b/lib/xixanta/src/assembler.rs
index 26d12b2..02414a7 100644
--- a/lib/xixanta/src/assembler.rs
+++ b/lib/xixanta/src/assembler.rs
@@ -83,7 +83,7 @@ impl MemoryRange {
     /// Display the range in hexadecimal format and by taking into consideration
     /// on whether it's really a range or a single value.
     pub fn range_to_human(&self) -> String {
-        if self.range.start + 1 == self.range.end {
+        if self.range.start + 1 >= self.range.end {
             if self.range.start <= 0xFF {
                 return format!("${:02X}", self.range.start);
             }