linux-kernel - Re: C aggregate passing (Rust kernel policy)

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: <20250227221801.63371d19@pumpkin>
Date: Thu, 27 Feb 2025 22:18:01 +0000
From: David Laight <david.laight.linux@...il.com>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: Ralf Jung <post@...fj.de>, Ventura Jack <venturajack85@...il.com>,
 Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Gary Guo
 <gary@...yguo.net>, torvalds@...ux-foundation.org, airlied@...il.com,
 boqun.feng@...il.com, ej@...i.de, gregkh@...uxfoundation.org,
 hch@...radead.org, hpa@...or.com, ksummit@...ts.linux.dev,
 linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: Re: C aggregate passing (Rust kernel policy)

On Thu, 27 Feb 2025 15:22:20 -0500
Kent Overstreet <kent.overstreet@...ux.dev> wrote:

> On Thu, Feb 27, 2025 at 08:45:09PM +0100, Ralf Jung wrote:
> > Hi,
> >   
> > > > > If C was willing to break code as much as Rust, it would be easier to
> > > > > clean up C.  
> > > > 
> > > > Is that true? Gcc updates do break code.  
> > > 
> > > Surely not as much as Rust, right? From what I hear from users
> > > of Rust and of C, some Rust developers complain about
> > > Rust breaking a lot and being unstable, while I instead
> > > hear complaints about C and C++ being unwilling to break
> > > compatibility.  
> > 
> > Stable Rust code hardly ever breaks on a compiler update. I don't know which
> > users you are talking about here, and it's hard to reply anything concrete
> > to such a vague claim that you are making here. I also "hear" lots of
> > things, but we shouldn't treat hear-say as facts.
> > *Nightly* Rust features do break regularly, but nobody has any right to
> > complain about that -- nightly Rust is the playground for experimenting with
> > features that we know are no ready yet.  
> 
> It's also less important to avoid ever breaking working code than it was
> 20 years ago: more of the code we care about is open source, everyone is
> using source control, and with so much code on crates.io it's now
> possible to check what the potential impact would be.

Do you really want to change something that would break the linux kernel?
Even a compile-time breakage would be a PITA.
And the kernel is small by comparison with some other projects.

Look at all the problems because python-3 was incompatible with python-2.
You have to maintain compatibility.

Now there are some things in C (like functions 'falling of the bottom
without returning a value') that could sensibly be changed from warnings
to errors, but you can't decide to fix the priority of the bitwise &.

	David


> 
> This is a good thing as long as it's done judiciously, to evolve the
> language towards stronger semantics and fix safety issues in the
> cleanest way when found.