Re: C aggregate passing (Rust kernel policy)

[Paul E. McKenney]

On Wed, Feb 26, 2025 at 09:59:41AM -0800, Linus Torvalds wrote:
> On Wed, 26 Feb 2025 at 05:54, Ralf Jung <post@xxxxxxxx> wrote:
> >
> >      The only approach we know that we can actually
> > pull through systematically (in the sense of "at least in principle, we can
> > formally prove this correct") is to define the "visible behavior" of the source
> > program, the "visible behavior" of the generated assembly, and promise that they
> > are the same.
> 
> That's literally what I ask for with that "naive" code generation, you
> just stated it much better.
> 
> I think some of the C standards problems came from the fact that at
> some point the standards people decided that the only way to specify
> the language was from a high-level language _syntax_ standpoint.
> 
> Which is odd, because a lot of the original C semantics came from
> basically a "this is how the result works". It's where a lot of the
> historical C architecture-defined (and undefined) details come from:
> things like how integer division rounding happens, how shifts bigger
> than the word size are undefined, etc. But most tellingly, it's how
> "volatile" was defined.
> 
> I suspect that what happened is that the C++ people hated the volatile
> definition *so* much (because of how they changed what an "access"
> means), that they then poisoned the C standards body against
> specifying behavior in terms of how the code *acts*, and made all
> subsequent C standards rules be about some much more abstract
> higher-level model that could not ever talk about actual code
> generation, only about syntax.

Yes, they really do seem to want something that can be analyzed in a
self-contained manner, without all of the mathematical inconveniences
posed by real-world hardware.  :-(

> And that was a fundamental shift, and not a good one.
> 
> It caused basically insurmountable problems for the memory model
> descriptions. Paul McKenney tried to introduce the RCU memory model
> requirements into the C memory model discussion, and it was entirely
> impossible. You can't describe memory models in terms of types and
> syntax abstractions. You *have* to talk about what it means for the
> actual code generation.

My current thought is to take care of dependency ordering with our
current coding standards combined with external tools to check these
[1], but if anyone has a better idea, please do not keep it a secret!

							Thanx, Paul

[1] https://people.kernel.org/paulmck/the-immanent-deprecation-of-memory_order_consume