On Fri Aug 21, 2026 at 4:37 PM JST, Alexandre Courbot wrote: > On Mon Aug 17, 2026 at 4:04 PM JST, Eliot Courtney wrote: >> It is currently possible to construct a non-`BitmapVec` backed >> `Bitmap` using `Bitmap::from_raw` that is larger than `i32::MAX`, and >> it is not part of the unsafe requirements. Restricting all bitmaps >> (even non-`BitmapVec` backed ones) to a maximum size of `i32::MAX` >> simplifies a few things and matches `BitmapVec::MAX_LEN`. > > Can we be more explicit (if possible in the doccomments as well) about > what "a few things" is? IIUC we are doing this because some of the C > APIs take an `int`, so we can just state that much.
Yeah, it somewhat depends on which version of the underlying C function is being called. The exact details vary between drm-rust-next's version and bitmap-for-next's version. Here is a (non-exhaustive?) list: - `copy_and_extend` truncates `len` to u32, which is wrong for > u32::MAX size - `__bitmap_set` and `__bitmap_clear` need i32 for size and u32 for start - so you couldn't run these on a `Bitmap` with a > i32::MAX size. - `next_zero_area_off` on bitmap-for-next can overflow without this restriction (we still have some overflow cases even with this restriction on 32-bit, or through `align_offset` in general) I'll add a note to the commit message and doccomment about the reasoning which IMO should more be about keeping the set of invariants between BitmapVec and Bitmap the same. > > Note also (as a point to consider, not a review ask) that we could > enforce this requirement in the type system if we made `nbits` a > `Bounded<usize, 31>`. Currently `from_raw` and `from_raw_mut` are > unsafe, so this becomes one more invariant for the caller to uphold, but > would we have made them unsafe just for this if they weren't already? I heard from Yury [1] that there is some work to eventually unify on unsigned longs. So I expect that the i32::MAX restriction may not be around forever. That's why I didn't do a change like Bounded here cos it's quite intrusive. [1]: https://lore.kernel.org/all/anELwosZSI5MZR4d@yury/
