On 12/2/25 3:20 PM, Joel Fernandes wrote: > On 12/2/2025 5:51 PM, Timur Tabi wrote: >> On Tue, 2025-12-02 at 16:23 -0500, Joel Fernandes wrote: ... >>> If img.size is not a multiple of 4 bytes, this can panic right?
Rust for Linux avoids .unwrap() for similar reasons that we prefer WARN*() over BUG*() these days, on the C side: avoid killing the machine if at all possible. Because it changes a routine bug into a harder-to-work-with bug. ... >> Wouldn't it be a run-time constraint anyway? With the exception of the >> BootloaderDmemDescV2 write, >> all of the calls to pio_wr_bytes() have lengths only known at runtime. > > I am not sure but I think rust code is expected to not panic and handle > situations gracefully even in the face of runtime constraints being violated, > you could argue that the image length being violated is UB but I don't think > that'd be enough to justify the unwrap(). But perhaps someone from the rust > core Agreed. This situation should return an -EINVAL Result, approximately. In fact, I just finished looking through my Hopper/Blackwell PIO code, which also needs 4-byte alignment, and concluded that returning -EINVAL for misaligned data seems to be the appropriate way to handle things. > team can chime in about that because I also have that question. Can a "FW > image > corruption" type of scenarios be considered something that safe rust code not > need to worry about since it falls under the UB umbrella (similar to memory > corruption)? > I'm not the core Rust team, but I will chime in anyway: misaligned or corrupted firmware should not *directly* cause a panic. We should detect and error out. thanks, -- John Hubbard
