On 10/9/2025 2:28 PM, Yury Norov wrote:
[..]>>>> regs::NV_PFALCON_FALCON_DMATRFBASE1::default()
>>>> - .set_base((dma_start >> 40) as u16)
>>>> + .try_set_base(dma_start >> 40)?
>>>> .write(bar, &E::ID);
>>>
>>> Does it mean that something like the following syntax is possible?
>>>
>>> regs::NV_PFALCON_FALCON_DMATRFBASE1::default()
>>> .try_set_base1(base1 >> 40)? // fail here
>>
>> Note that try_set_base1() returns a Result [1], which is handled
immediately by
>> the question mark operator [2]. I.e. if try_set_base1() returns an
error it is
>> propagated to the caller right away without executing any of the code
below.
>
> Thanks for the links. I am definitely the very beginning on the
> learning curve for this.
>
>>> .try_set_base2(base2 >> 40)? // skip
>>> .write(bar, &E::ID) else { pr_err!(); return
-EINVAL };
>>>
>>> This is my main concern: Rust is advertised a as runtime-safe
language
>>> (at lease safer than C), but current design isn't safe against
one of
>>> the most common errors: type overflow.
>>
>> Where do you see a potential runtime overflows in the register!() code?
>
> Assuming base is 10-bit,
>
> let ret = some_c_wrapper() // 0..1024 or -EINVAL
> regs::NV_PFALCON_FALCON_DMATRFBASE1::default()
> .try_set_base1(ret)
>
> Or maybe I misunderstood the question, because if there's no
possibility
> to overflow a field, what for the .try_set_xxx() is needed at all?
Because 'ret' is a value determined at runtime in this example, there is
no way
for the compiler to know that ret will fit into the bounded int, at compile
time. So the "try_" means it is runtime checked and validated (via
return of
Result). Sure it may well not fail, but the compiler doesn't know that.
Thanks.