Re: C aggregate passing (Rust kernel policy)

[David Laight <david.laight.linux@gmail.com>]

On Wed, 26 Feb 2025 09:59:41 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Wed, 26 Feb 2025 at 05:54, Ralf Jung <post@ralfj.de> 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.

I'm pretty sure some things were 'undefined' to allow more unusual
cpu to be conformant.
So ones with saturating integer arithmetic, no arithmetic right shift,
only word addressing (etc) could still claim to be C.
There is also the NULL pointer not being the 'all zeros' pattern.
I don't think any C compiler has ever done that, but clang has started
complaining that maths with NULL is undefined because that is allowed.
Is it going to complain about memset() of structures containing pointers?

The other problem is that it says 'Undefined Behaviour' not 'undefined
result' or 'may trap'. UB includes 'erasing all the data on your disk'.

	David