[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87349dw84x.fsf@t14s.mail-host-address-is-not-set>
Date: Wed, 27 Aug 2025 09:12:14 +0200
From: Andreas Hindborg <a.hindborg@...nel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, FUJITA Tomonori
<fujita.tomonori@...il.com>
Cc: alex.gaynor@...il.com, ojeda@...nel.org, aliceryhl@...gle.com,
anna-maria@...utronix.de, bjorn3_gh@...tonmail.com, boqun.feng@...il.com,
dakr@...nel.org, frederic@...nel.org, gary@...yguo.net,
jstultz@...gle.com, linux-kernel@...r.kernel.org, lossin@...nel.org,
lyude@...hat.com, rust-for-linux@...r.kernel.org, sboyd@...nel.org,
tglx@...utronix.de, tmgross@...ch.edu, acourbot@...dia.com,
daniel.almeida@...labora.com
Subject: Re: [PATCH v1 1/2] rust: add udelay() function
"Miguel Ojeda" <miguel.ojeda.sandonis@...il.com> writes:
> On Tue, Aug 26, 2025 at 1:59 PM FUJITA Tomonori
> <fujita.tomonori@...il.com> wrote:
>>
>> This can lead to an unexpected delay duration, but it's safe in Rust’s
>> sense of safety?
>
> If it is just unexpected behavior, then yeah.
>
> Perhaps Andreas is referring to C overflow UB? If that is the case,
> then in the kernel it is actually defined due to
> `-fno-strict-overflow`.
OK, cool Then I would suggest that we just add a small note in the docs
about the C behavior that even though passing an invalid value is
considered a bug, it will not cause UB or memory unsafety.
Best regards,
Andreas Hindborg
Powered by blists - more mailing lists