Re: A few proposals, this time from the C++ standards committee

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, 5 Jun 2024 at 06:52, Paul E. McKenney <paulmck@kernel.org> wrote:
>
> n3243 A Memory model with Synchronization based type aliasing V1,
>         Eskil Steenberg Hald
>         https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3243.pdf

I love the part that admits that the type-based aliasing is broken.

I don't think the "cast-based barriers" are a sufficient improvement.

Note the "sufficient". I do think a cast-based barrier would have been
a huge improvement *originally*, in that it would avoid two absolutely
huge issues:

 - "char *" being special

 - the insane model of "use a union to tell the compiler type-base
aliasing can happen"

Both of the above things are disgusting and wrong, but they are mostly
disgusting and wrong simply because type-based aliasing is entirely
and utterly wrong to begin with.

Saying "pointer casts are an aliasing barrier" is a much better and
more logical model for the type-based thing. No question about that.
They help make the insanity that is type-based aliasing much more
manageable.

However, I don't see that it would be sufficient for us to ever stop
using the "-fno-strict-aliasing" thing. Because type-based aliasing
continues to be insane, and even with pointer casting acting as a
barrier, has real problems.

The paper points out one such problem: the cast may have been done
long long before the accesses are done. In fact, unions continue to be
one very real case of such a situation, where the pointer cast
basically comes from the type system itself.

But even with explicit casts, those casts may very naturally be before
the accesses (the examples in the paper are simplistic, but we have
the "prepare casts" pattern in the kernel in places like this:

  static long do_fcntl(int fd, unsigned int cmd, unsigned long arg,
                struct file *filp)
  {
        void __user *argp = (void __user *)arg;
        int argi = (int)arg;
        ...

which admittedly isn't about two pointers that can alias, but is very
much an example of "it's more convenient to 'prep' the casts before
use", when the 'arg' argument is then used in multiple different ways
- sometimes as a pointer, sometimes as an integer, and sometimes as
the original 'unsigned long'.

I personally think that the whole type-based aliasing is fundamentally
unfixable, and that the C standards committee should just admit that.
It doesn't even *work*, because often the types are the same anyway,
even when you really really want to say "these accesses can't alias".

The whole type-based aliasing is literally designed for - and by - HPC
people who (a) had no taste, (b) didn't understand language design and
just hacked sh*t together and (c) were working with clearly distinct
types because their workloads are trivial.

The HPC people literally tried to solve the issue of "counters are
integers, but our data is FP, and the two have obviously different
types, so let's use that information for alias analysis".

Anybody who doesn't understand how broken and hacky that is SHOULD NOT
BE ON A LANGUAGE COMMITTEE.

Seriously. I think it should be a fundamental filter for any C
language committee member: "Do you think type-based aliasing makes
sense?". If you get anything but an immediate "No!",  you pull the
lever that opens the trap-door to the crocodile-infested waters below.

Or sharks. Sharks are good too.

And no, "restrict" isn't great, but at least it's a better concept.

I would suggest that people look at improving 'restrict' and making it
more useful, and just admit that the type-based thing was a mistake.

                        Linus