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
next prev parent 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).