On Sun Jun 21, 2026 at 5:41 PM CEST, Gary Guo wrote: > On Sun Jun 21, 2026 at 10:17 AM BST, Alexandre Courbot wrote: >> As you can see, this lets a 32-bit access be done on the upper half of a >> 64-bit register, which sounds like it should not be allowed? Similarly one >> could change register types, and so on. This might not be "unsafe" in the >> sense that it is still aligned and in bounds, but it lets the structure set >> by the type system be bypassed. It could also potentially be a violation of >> the hardware contract if the access width is relevant for this particular >> address. > > I see no reason to prevent any of the case, this can be done by `try_cast()` > API as well. If we need to take access width restriction and other > restrictions into consideration, then a lot of API cannot be exposed at all. > E.g. it is not okay to add `copy_read`/`copy_write` like the patch 19, because > it uses memcpy_from/toio which is possibility doing byte-width access. > > in my opinion think people should be able to type casting without reaching out > to `unsafe` if it's not UB. Similar to the logic on why we have `zerocopy` > that allows casting between to types, these are "bypassing the typesystem" as > well!
I think this is fine as-is. The natural, ergonomic path through the API (io_read!/io_write!/io_project! macros, IoLoc-based accessors, etc.) leads users toward correct access widths. Whether through io_addr() or a custom IoLoc implementation, reinterpreting the access type requires explicit, deliberate choices: picking a different type and computing a byte offset. This is not something anyone would do by accident. So, as long as the API doesn't provide a subtle way to do the wrong thing by accident, I don't think we need to add restrictions here.
