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.
