Re: [PATCH v2 1/6] rust: io: turn IoCapable into a functional trait

[Gary Guo]

On Thu Feb 12, 2026 at 8:04 PM CST, Alexandre Courbot wrote:
> Hi Lyude,
>
> On Sat Feb 7, 2026 at 5:29 AM JST, lyude wrote:
>> On Fri, 2026-02-06 at 15:00 +0900, Alexandre Courbot wrote:
>>> `IoCapable<T>` is currently used as a marker trait to signal that the
>>> methods of the `Io` trait corresponding to `T` have been overridden
>>> by
>>> the implementor (the default implementations triggering a build-time
>>> error).
>>> 
>>> This goes against the DRY principle and separates the signaling of
>>> the
>>> capability from its implementation, making it possible to forget a
>>> step
>>> while implementing a new `Io`.
>>
>> I realized another thing that might be missing from this series while
>> porting the iosys_map code over: it seems like IoCapable is fine being
>> a safe trait, but Io and IoKnownSize both seem like they should
>> actually be unsafe traits. The main reason being that IoCapable doesn't
>> actually provide any methods that provide a guarantee of being able to
>> read/write from the IO space, but Io does - and IoKnownSize is making
>> the guarantee the IO space is at least of size IoKnownSize::MIN_SIZE.
>
> Mmm I think you are correct. For instance, nothing prevents someone from
> implementing `Io` with bogus `addr()` and `maxsize()` methods, which
> would trigger undefined behavior with purely safe code.

They can, but the `Io` trait just passes the wrong address to the `IoCapable`
trait, and nothing horrible can happen without doing things unsafely inside
`IoCapable` impl, which is controlled by the user who implements `Io`. It looks
to me that unsafe code is still needed to do bogus things.

Can you give a more detailed example on how safe code can cause issue with a
safe `Io` trait?

Best,
Gary