Received-SPF: pass (google.com: domain of linux-kernel+bounces-35858-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240122184608.11863-1-dakr@redhat.com> <2024012252-attempt-tables-e3fc@gregkh>
 <Za7uampZiG2IP8dE@cassiopeiae> <2024012251-geriatric-morphine-a275@gregkh> <Za_2WuQh9vr2Na7S@pollux>
In-Reply-To: <Za_2WuQh9vr2Na7S@pollux>
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date: Tue, 23 Jan 2024 19:18:57 +0100
Message-ID: <CANiq72=mrbRXcKGOC9M5=-_cP5ShnYGLF7t8Dt7WDCP+xffK-A@mail.gmail.com>
Subject: Re: [PATCH] rust: str: add to_ascii_{upper,lower}case() to CString
To: Danilo Krummrich <dakr@redhat.com>
Cc: Greg KH <gregkh@linuxfoundation.org>, ojeda@kernel.org, alex.gaynor@gmail.com, 
	wedsonaf@gmail.com, boqun.feng@gmail.com, gary@garyguo.net, 
	bjorn3_gh@protonmail.com, benno.lossin@proton.me, a.hindborg@samsung.com, 
	aliceryhl@google.com, rust-for-linux@vger.kernel.org, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 23, 2024 at 6:24=E2=80=AFPM Danilo Krummrich <dakr@redhat.com> =
wrote:
>
> We also need to consider that simply wrapping tolower() and toupper() wou=
ld 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 interestin=
g 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 t=
he
> 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