Message-ID: <CAFJgqgR4Q=uDKNnU=2yo5zoyFOLERG+48bFuk4Dd-c+S6x+N5w@mail.gmail.com>
Date: Wed, 26 Feb 2025 11:09:06 -0700
From: Ventura Jack <venturajack85@...il.com>
To: Ralf Jung <post@...fj.de>
Cc: Kent Overstreet <kent.overstreet@...ux.dev>, 
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Gary Guo <gary@...yguo.net>, 
	torvalds@...ux-foundation.org, airlied@...il.com, boqun.feng@...il.com, 
	david.laight.linux@...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 Wed, Feb 26, 2025 at 9:32 AM Ralf Jung <post@...fj.de> wrote:
>
> Hi VJ,
>
> >>
> >>> - Rust has not defined its aliasing model.
> >>
> >> Correct. But then, neither has C. The C aliasing rules are described in English
> >> prose that is prone to ambiguities and misintepretation. The strict aliasing
> >> analysis implemented in GCC is not compatible with how most people read the
> >> standard (https://bugs.llvm.org/show_bug.cgi?id=21725). There is no tool to
> >> check whether code follows the C aliasing rules, and due to the aforementioned
> >> ambiguities it would be hard to write such a tool and be sure it interprets the
> >> standard the same way compilers do.
> >>
> >> For Rust, we at least have two candidate models that are defined in full
> >> mathematical rigor, and a tool that is widely used in the community, ensuring
> >> the models match realistic use of Rust.
> >
> > But it is much more significant for Rust than for C, at least in
> > regards to C's "restrict", since "restrict" is rarely used in C, while
> > aliasing optimizations are pervasive in Rust. For C's "strict aliasing",
> > I think you have a good point, but "strict aliasing" is still easier to
> > reason about in my opinion than C's "restrict". Especially if you
> > never have any type casts of any kind nor union type punning.
>
> Is it easier to reason about? At least GCC got it wrong, making no-aliasing
> assumptions that are not justified by most people's interpretation of the model:
> https://bugs.llvm.org/show_bug.cgi?id=21725
> (But yes that does involve unions.)

For that specific bug issue, there is a GitHub issue for it.

    https://github.com/llvm/llvm-project/issues/22099

And the original test case appears to have been a compiler bug
and have been fixed, at least when I run on Godbolt against
a recent version of Clang. Another comment says.

    "The original testcase seems to be fixed now but replacing
    the union by allocated memory makes the problem come back."

And the new test case the user mentions involves a void pointer.

I wonder if they could close the issue and open a new issue
in its stead that only contains the currently relevant compiler
bugs if there are any. And have this new issue refer to the old
issue. They brought the old issue over from the old bug tracker.
But I do not have a good handle on that issue.

Unions in C, C++ and Rust (not Rust "enum"/tagged union) are
generally sharp. In Rust, it requires unsafe Rust to read from
a union.

> > [Omitted]
>
> Okay, fair. But it is easy to misunderstand the other items in your list in
> isolation.

I agree, I should have made it unambiguous and made each item
not require the context of other items, or have made the
dependencies between items clearer, or some other way.
I remember not liking the way I organized it, but did not
improve it before sending, apologies.

> >>
> >> [Omitted].
> >
> > I do not believe that you are correct when you write:
> >
> >      "Unlike sanitizers, Miri can actually catch everything."
> >
> > Critically and very importantly, unless I am mistaken about MIRI, and
> > similar to sanitizers, MIRI only checks with runtime tests. That means
> > that MIRI will not catch any undefined behavior that a test does
> > not encounter. If a project's test coverage is poor, MIRI will not
> > check a lot of the code when run with those tests. Please do
> > correct me if I am mistaken about this. I am guessing that you
> > meant this as well, but I do not get the impression that it is
> > clear from your post.
>
> Okay, I may have misunderstood what you mean by "catch everything". All
> sanitizers miss some UB that actually occurs in the given execution. This is
> because they are inserted in the pipeline after a bunch of compiler-specific
> choices have already been made, potentially masking some UB. I'm not aware of a
> sanitizer for sequence point violations. I am not aware of a sanitizer for
> strict aliasing or restrict. I am not aware of a sanitizer that detects UB due
> to out-of-bounds pointer arithmetic (I am not talking about OOB accesses; just
> the arithmetic is already UB), or UB due to violations of "pointer lifetime end
> zapping", or UB due to comparing pointers derived from different allocations. Is
> there a sanitizer that correctly models what exactly happens when a struct with
> padding gets copied? The padding must be reset to be considered "uninitialized",
> even if the entire struct was zero-initialized before. Most compilers implement
> such a copy as memcpy; a sanitizer would then miss this UB.
>
> In contrast, Miri checks for all the UB that is used anywhere in the Rust
> compiler -- everything else would be a critical bug in either Miri or the compiler.
> But yes, it only does so on the code paths you are actually testing. And yes, it
> is very slow.

I may have been ambiguous again, or unclear or misleading,
I need to work on that.

The description you have here indicates that Miri is in many ways
significantly better than sanitizers in general.

I think it is more accurate of me to say that Miri in some aspects
shares some of the advantages and disadvantages of sanitizers,
and in other aspects is much better than sanitizers.

Is Miri the only one of its kind in the programming world?
There are not many system languages in mass use, and
those are the languages that first and foremost deal
with undefined behavior. That would make Miri extra impressive.

>

There are some issues in Rust that I am curious as to
your views on. rustc or the Rust language has some type
system holes, which still causes problems for rustc and
their developers.

    https://github.com/lcnr/solver-woes/issues/1
    https://github.com/rust-lang/rust/issues/75992

Those kinds of issues seem difficult to solve.

In your opinion, is it accurate to say that the Rust language
developers are working on a new type system for
Rust-the-language and a new solver for rustc, and that
they are trying to make the new type system and new solver
as backwards compatible as possible?

Best, VJ.

Powered by blists - more mailing lists