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

["Paul E. McKenney" <paulmck@kernel.org>]

On Wed, Jun 05, 2024 at 11:08:40AM -0700, Linus Torvalds wrote:
> 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".

All good points!

> 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.

To your point, my feeling back in the day was that all of this was
designed to allow FORTRAN programs to be more easily ported to C and C++.

> 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.

One of the complaints was that people don't use "restrict" often enough
to allow all the optimizations that compiler writers would like to do.
Fortunately, there seems to be increasing levels of understanding that
the generated code needs to do something useful.  Here is hoping, anyway!

							Thanx, Paul