linux-kernel - Re: [PATCH] rust: init: change the generated name of guard variables

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 17 Apr 2024 15:20:37 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Gary Guo <gary@...yguo.net>
Cc: Boqun Feng <boqun.feng@...il.com>, Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, Wedson Almeida Filho <wedsonaf@...il.com>, Björn Roy Baron <bjorn3_gh@...tonmail.com>, Andreas Hindborg <a.hindborg@...sung.com>, Alice Ryhl <aliceryhl@...gle.com>, Martin Rodriguez Reboredo <yakoyoku@...il.com>, rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rust: init: change the generated name of guard variables

On 17.04.24 17:06, Gary Guo wrote:
> On Wed, 03 Apr 2024 22:09:49 +0000
> Benno Lossin <benno.lossin@...ton.me> wrote:
> 
>> On 03.04.24 23:20, Boqun Feng wrote:
>>> On Wed, Apr 03, 2024 at 07:43:37PM +0000, Benno Lossin wrote:
>>>> The initializers created by the `[try_][pin_]init!` macros utilize the
>>>> guard pattern to drop already initialized fields, when initialization
>>>> fails mid-way. These guards are generated to have the same name as the
>>>> field that they handle. To prevent namespacing issues when the field
>>>
>>> Do you have an example of this kind of issues?
>>
>> https://lore.kernel.org/rust-for-linux/1e8a2a1f-abbf-44ba-8344-705a9cbb1627@proton.me/
>>
> 
> Here's the simplified example:
> 
> ```
> macro_rules! f {
>      () => {
>          let a = 1;
>          let _: u32 = a;
>      }
> }
> 
> const a: u64 = 1;
> 
> fn main() {
>      f!();
> }
> ```
> 
> The `a` in `f` have a different hygiene so normally it is scoped to the
> macro expansion and wouldn't escape. Interestingly a constant is still
> preferred despite the hygiene so constants escaped into the macro,
> leading to the error.
> 
> Would your change regress error message when `pin_init!` is used
> wrongly? Personally I would say this kind of error is niche enough
> (given the casing of constants and variables differ) that we probably
> don't really need to care. So if error message would be affected then
> we'd better off not making the change.

For all the tested error messages (see [1]) there is absolutely no
difference in the diagnostic.

[1]: https://github.com/Rust-for-Linux/pinned-init/tree/main/tests/ui/compile-fail

-- 
Cheers,
Benno