linux-kernel - Re: [PATCH v2 1/1] rust: kernel: create `overflow

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]

Message-ID: <20250506042330.281501-1-contact@antoniohickey.com>
Date: Tue,  6 May 2025 00:23:30 -0400
From: Antonio Hickey <contact@...oniohickey.com>
To: miguel.ojeda.sandonis@...il.com
Cc: a.hindborg@...nel.org,
	alex.gaynor@...il.com,
	aliceryhl@...gle.com,
	benno.lossin@...ton.me,
	bjorn3_gh@...tonmail.com,
	boqun.feng@...il.com,
	contact@...oniohickey.com,
	dakr@...nel.org,
	gary@...yguo.net,
	linux-kernel@...r.kernel.org,
	ojeda@...nel.org,
	rust-for-linux@...r.kernel.org,
	tmgross@...ch.edu
Subject: Re: [PATCH v2 1/1] rust: kernel: create `overflow_assert!`

On Sun, May 04, 2025 at 09:41:36PM +0200, Miguel Ojeda wrote:
> I was thinking of just allowing any expression here. I can see the
> value in printing the values, but it makes it a bit harder to remember
> the comparison and is less flexible -- I can imagine we will have
> other operators being used, or even things that are not tested via an
> operator.

Oh wow yea this could be so much more flexible allowing any expression,
didn't even think of this now my approach feels so naive haha.

> By the way, would it be possible to have the `cfg` attribute inside
> the macro, so that we share the docs and so on? i.e. to make the
> conditional compilation as local as possible even here :)
> 
> i.e. as it is currently done, we can have mistake like not sharing the
> "signature", and the generated docs will not have the actual docs of
> the macro if it is disabled.

I originally thought we couldn't do conditional compilation in macros,
but I'm looking into it now and it seems possible, I'll have to test 
this.

> We could also consider using the `cfg!` macro to force it to be always
> valid code -- not sure about whether we want that in all cases though.
> The standard library does that, though, so perhaps we should do the
> same for consistency. If someone really wants to skip it, they can
> always do it on the caller side.

I do like the idea utilizing the `cfg!` macro, it's cleaner as it 
reduces the empty boilerplate currently required. I do wonder though
could that potentially cause warnings like unreachable code or 
unused variables?