Re: Rust kernel policy

H. Peter Anvin
2025-02-20T13:24:10Z

On February 20, 2025 4:37:46 AM PST, Greg KH <gregkh@linuxfoundation.org> wrote:
>On Thu, Feb 20, 2025 at 01:28:58PM +0100, Jan Engelhardt wrote:
>>
>> On Wednesday 2025-02-19 06:39, Greg KH wrote:
>> >
>> >The majority of bugs (quantity, not quality/severity) we have are due to
>> >the stupid little corner cases in C that are totally gone in Rust.
>>
>> If and when Rust receives its own corner cases in the future,
>> I will happily point back to this statement.
>
>I'm not saying that rust has no such issues, I'm saying that a huge
>majority of the stupid things we do in C just don't happen in the same
>code implemented in rust (i.e. memory leaks, error path cleanups, return
>value checking, etc.)
>
>So sure, let's make different types of errors in the future, not
>continue to make the same ones we should have learned from already
>please :)
>
>thanks,
>
>greg k-h
>

I would like to point out that quite frankly we have been using a C style which is extremely traditional, but which have been known to cause problems many times; specifically, using *alloc, memcpy() and memset() with explicit sizes; migrating towards using sizeof() but still having to type it explicitly, and the known confusion of sizeof(ptr) and sizeof(*ptr). This could and probably should be macroized to avoid the redundancy.

In the NASM codebase I long ago started using nasm_new() and nasm_zero() macros for this purpose, and structure copies really can just be aasignment statements. People writing C seem to have a real aversion for using structures as values (arguments, return values or assignments) even though that has been valid since at least C90 and can genuinely produce better code in some cases.