Grid::insert_{row, col}()
can create invalid states after panicking
#19
Labels
bug
Something isn't working
The
Grid
type has the effective safety invariants thatrows.checked_mul(cols) == Some(data.len())
and thatrows == 0
if and only ifcols == 0
. In some panicking paths,Grid::insert_row()
can violate these invariants:grid.insert_row(i, row)
in release mode, whererow.len() == grid.cols
andgrid.rows == usize::MAX
. This setsgrid.rows
to 0, making the other methods' results inconsistent with one another. This is only possible whensize_of::<T>() == 0
, and I'm not sure if it can cause any UB by itself.grid.insert_row(i, row)
, wherei <= grid.rows
,row.len() == grid.cols
,grid.rows < usize::MAX
, andgrid.rows * grid.cols > usize::MAX - grid.cols
: This incrementsgrid.rows
without pushing the new row, allowing invalidget_unchecked()
calls. Since this is only possible whensize_of::<T>() == 0
, it causes library UB but not language UB with the current standard library.grid.insert_row(i, row)
, wherei <= grid.rows
,row.len() == grid.cols
,size_of::<T>() > 0
, and(grid.rows + 1) * grid.cols * size_of::<T>() > isize::MAX as usize
. This incrementsgrid.rows
without pushing the new row, which can cause UB on 32-bit targets:The text was updated successfully, but these errors were encountered: