Il mar 8 lug 2025, 11:11 Manos Pitsidianakis <manos.pitsidiana...@linaro.org>
ha scritto:

> > I find this both verbose and (ok, that's subjective) ugly due to the
> > extra import, the underscore.
>
> Yep, I agree on that, but I wasn't sure what name would be better.
> Whatever type-level improvement this patch brings, it's small, though
> nice-to-have. We can drop it, no problem.
>

You did identify a small but real problem, which can be fixed with
assertions.

And also another issue in the API, which is that some code likes to use bit
sizes and other likes to use byte sizes. And it's not clear whether you
have to do *8 or /8.

This is the one that is where an enum does work great, but without the "as"
(because it reintroduces the *8 or /8 problem) and with names that don't
have digits (because of the underscore, but also because it makes the
result of "as" confusing).

Byte/Word/Long/Quad would work for me, as it matches the C stb/stw/stl/stq
APIs. Also please add the enum to the prelude. Still verbose but readable.
I would also add methods like nbits() and nbytes() that can be used instead
of "as".

Of course if you go with the enum there is no need for assertions in the
memory API. Except for the >= one, so perhaps it would also make sense to
implement Cmp in addition to Eq?

> The main effect on generated code is to add an assert! to
> > memory_region_ops_read_cb() and memory_region_ops_write_cb() that's
> > similar to the above.  I'm not sure of its value, either: if the size is
> > not 1/2/4/8, memory.c/physmem.c must have screwed up big.  It's not a
> > safety concern, either, since the size is not used in any unsafe code.
>
> Yep it's more of a guard rail since we can't have refined integer types.
>

It's not a lot in the grand scheme of things, but adding a match around all
reads and writes isn't great. :(

The only way to make an enum from an integer of the same repr is via
transmute, right? So probably there could be an unsafe method
Size::from_unchecked(u32) too?

Paolo


> --
> Manos Pitsidianakis
> Emulation and Virtualization Engineer at Linaro Ltd
>
>

Reply via email to