Re: [PATCH] rust: str: add to_ascii_{upper,lower}case() to CString

[Miguel Ojeda]

On Tue, Jan 23, 2024 at 6:24 PM Danilo Krummrich <dakr@xxxxxxxxxx> 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