rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Benno Lossin" <lossin@kernel.org>
To: "Timur Tabi" <ttabi@nvidia.com>,
	"ojeda@kernel.org" <ojeda@kernel.org>,
	"dakr@kernel.org" <dakr@kernel.org>,
	"aliceryhl@google.com" <aliceryhl@google.com>,
	"rust-for-linux@vger.kernel.org" <rust-for-linux@vger.kernel.org>
Subject: Re: [PATCH] rust: introduce sfile macro for easier code tracing
Date: Tue, 03 Jun 2025 23:54:01 +0200	[thread overview]
Message-ID: <DAD8DI7Q8YV8.OKUS6GUZDLQF@kernel.org> (raw)
In-Reply-To: <2846f3423a0641c54ef0368308549fe51c06565b.camel@nvidia.com>

On Tue Jun 3, 2025 at 7:15 PM CEST, Timur Tabi wrote:
> On Thu, 2025-05-29 at 22:14 +0200, Benno Lossin wrote:
>> > 
>> > The macro goes avoids str::rfind() because currently, that function is not
>> > const.  The compiler emits a call to memrchr, even when called on string
>> > literals.  Instead, the macro implements its own versions of rfind(),
>> > allowing the compiler to generate the slice at compile time.
>> > 
>> > Unfortunately, Rust does not consider the .. operator to be const either,
>> > so sfind!() cannot be assigned to consts.  For example, the following will
>> > not compile:
>> 
>> This is not the `..` operator, but rather the index operation of a str
>> (`&FILE[start..]`). It can be made const by using `from_utf8` [1] and
>> manually creating the correct byte slice using `unsafe` [2] instead.
>> 
>> [1]: https://doc.rust-lang.org/std/str/fn.from_utf8.html
>> [2]: https://doc.rust-lang.org/std/slice/fn.from_raw_parts.html
>
>
> Ok, it took a lot of trial-and-error on my part, but I got this to work.

Great!

> It's not pretty, though.  Is this what you intended?
>
>         let start = find_last_or_zero(FILE, '/') + 1;
>         let end = find_last_or_len(FILE, '.');
>         
>         let base_ptr: *const u8 = FILE.as_ptr();
>         let ptr: *const u8 = unsafe { base_ptr.add(start) };
>         let slice = unsafe { core::slice::from_raw_parts(ptr, end - start) };
>         unsafe { core::str::from_utf8_unchecked(slice) }

Yeah that's roughly what I had in mind.

Maybe we should check that `end >= start` in case the filename is empty
(which shouldn't happen)? I'm not sure what happens with overflows /
other `unsafe` precondition violations...

> The good news is that this allows
>
> 	const SFILE: &'static str = sfile!();
>
> to work, so thank you.

That'll be useful :)

---
Cheers,
Benno

  reply	other threads:[~2025-06-03 21:54 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-29 18:45 [PATCH] rust: introduce sfile macro for easier code tracing Timur Tabi
2025-05-29 20:14 ` Benno Lossin
2025-06-03 17:15   ` Timur Tabi
2025-06-03 21:54     ` Benno Lossin [this message]
2025-05-29 20:21 ` Miguel Ojeda
2025-06-03 18:15   ` Timur Tabi
2025-06-03 21:58     ` Benno Lossin
2025-06-03 22:05       ` Timur Tabi
2025-06-03 22:15         ` Miguel Ojeda
2025-06-04 23:12           ` Timur Tabi
2025-06-05  3:20             ` Miguel Ojeda
2025-06-03 22:15     ` Miguel Ojeda
2025-06-03 23:29       ` Timur Tabi
2025-06-04 10:28         ` Miguel Ojeda
2025-06-04 15:16           ` Benno Lossin
2025-06-04 15:41             ` Miguel Ojeda
2025-06-05  6:05             ` Greg KH
2025-06-04 20:38           ` Timur Tabi
2025-06-05  6:07             ` Greg KH
2025-06-05 15:02               ` Timur Tabi
2025-06-05 15:21                 ` gregkh
2025-06-05 15:38                   ` Miguel Ojeda
2025-06-05 16:42                     ` gregkh
2025-06-05 17:39                       ` Miguel Ojeda
2025-06-06 15:50                 ` Miguel Ojeda
2025-05-30  3:47 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DAD8DI7Q8YV8.OKUS6GUZDLQF@kernel.org \
    --to=lossin@kernel.org \
    --cc=aliceryhl@google.com \
    --cc=dakr@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=ttabi@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).