linux-kernel - Re: [PATCH] rust: str: add to_ascii

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: <CANiq72=mrbRXcKGOC9M5=-_cP5ShnYGLF7t8Dt7WDCP+xffK-A@mail.gmail.com>
Date: Tue, 23 Jan 2024 19:18:57 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Danilo Krummrich <dakr@...hat.com>
Cc: Greg KH <gregkh@...uxfoundation.org>, ojeda@...nel.org, alex.gaynor@...il.com, 
	wedsonaf@...il.com, boqun.feng@...il.com, gary@...yguo.net, 
	bjorn3_gh@...tonmail.com, benno.lossin@...ton.me, a.hindborg@...sung.com, 
	aliceryhl@...gle.com, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rust: str: add to_ascii_{upper,lower}case() to CString

On Tue, Jan 23, 2024 at 6:24 PM Danilo Krummrich <dakr@...hat.com> wrote:
>
> We also need to consider that simply wrapping tolower() and toupper() would make
> slice::make_ascii_{lower,upper]case(), str::make_ascii_{lower,upper]case(),
> char::make_ascii_{lower,upper]case() and CString::make_ascii_{lower,upper]case()
> inconsistent. The former ones already only consider 'a' to 'z' and 'A' to 'Z'
> respectively.

Latter, right? i.e. the kernel ones are the ones that consider the
extended ones.

> Just to clarify, personally I'm not worried about whether we consider the
> extended range in this specific case or not. I think it's more interesting to
> generlly figure out if, for such modules, we want the caller to expect C
> bindings to be called or C logic to applied respectively, or if we want the
> caller to expect that everything is aligned with the Rust std library.

Yeah, it is normal to provide Rust abstractions that follow the naming
and logic of the C side. Having said that, in this particular case, as
you say, since some of these APIs are already in Rust's `core`, I
think it is OK to have the Rust ones completed for `CString` etc. But
if we are to provide the C logic, then we should use the C names.

In other words, in general, what we should definitely avoid is mixing
them, i.e. using the C logic when Rust std names are used, or vice
versa. And maybe we need both the C and the Rust ones in some cases
(should be rare, since it is likely only to come up for things in
`core` like this or perhaps for well-known things in, say, `std`, but
at least for those we do not use them in the kernel so it is a bit
less confusing).

Similarly, it does not hurt to mention whether an API has any subtle
difference (or not) with a similar C API. Sadly, we cannot (easily) do
that also for the existing ones already in `core` too, but it is not a
big deal.

Cheers,
Miguel