Message-ID: <979af7ae9b7e8baf080ef6f8d42d48d7f5d2c5b4.camel@tugraz.at>
Date:   Sat, 26 Feb 2022 02:21:27 +0100
From:   Martin Uecker <uecker@...raz.at>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 03/13] usb: remove the usage of the list iterator
 after the loop

Am Freitag, den 25.02.2022, 14:02 -0800 schrieb Linus Torvalds:
> On Fri, Feb 25, 2022 at 1:36 PM Uecker, Martin
> <Martin.Uecker@....uni-goettingen.de> wrote:
> > Implementation-defined only means that it needs to be
> > documented (and clang does not even do this), so
> > I am not sure what difference this would make.
> 
> No, implementation-defined means something *much* more than "undefined".
> 
> Yes, it means that the behavior has to be documented.
> 
> But that's not actually the big deal from a user standpoint (although
> it might be a big annoyance from a compiler writer's standpoint -
> compiler writers would probably much prefer "let me do the obvious
> sane thing" over "let me do the obvious sane thing and then have to
> write documentation about how obviously sane it is").
> 
> From a user standpoint, the big thing is that "implementation-defined"
> means that the behavior has to have *SOME* well-defined behavior.
> Documentation is irrelevant. But RELIABILITY is relevant.
> 
> See?

In principle, a compiler writer could document
implementation-defined behavior to do something
crazy and promise that something the standard
leaves undefined has useful and consistent behavior.

But I think you are right that this still makes
a huge difference in practice because the two
notions encourage different things.

...

> In contrast, "undefined" means that the same C code can do two totally
> different things with different optimization options, or based on just
> any random thing - like some random register allocation issue.
> 
> So "undefined" behavior means that changes to code that isn't even
> near the code in question can change what the code generation for that
> code is. And the compiler may not even report it.

Yes, it means the compiler is free to do this.

But it does not mean a compiler *has* to do this.

Compiler writers represented in the committee want
to have the UB because some customers seem to like
those optimizations. At the same time, a programmer
who complains about some undesired effect of such
an UB-based optimization is typically told that the
program has UB according to the C standard so
nothing can be done (bug report closed).

You see what is happening here?

Roughly the same group of people / companies that
write the compilers also control what goes into the
standard. They then like to point to the standard
and reject all responsibility for *their*
implementation choices.  By complaining about
the standard, one detracts from the fact that
the compiler writers make these choices and
also largely control what goes in the standard.


> That is a complete disaster. It's a disaster from a security
> standpoint, it's a disaster from a maintenance standpoint, it's just
> *bad*.

It is sometimes pure necessity. An unbounded write
has unbounded consequences and there is no realistic
way to give it defined behavior (in the context
of C).  But for many other cases of UB, I completely
agree with you.

> And the C standards committee has traditionally used to think it was a
> good thing, because they listened to compiler writers that claimed
> that it allowed them to do wild optimizations and improve code
> generation.

There are many compiler people in the standards committee,
so there is no surprise here.

> Example: the completely broken type-based aliasing rules that changed
> semantics of C for the worse.

I do not really know the history of this, but
I think these rules existed even before compilers
really exploited them for optimization.

> Reality: it doesn't actually improve code generation all that much.
> Instead it just results in a lot of problems, and any sane C code base
> that cares about security and stability will just turn that off.
> 
> Same goes for integer overflow etc.

For signed overflow, I am not entirely sure what the
right choice is.  Wrapping for signed overflow also seems
dangerous. I use UBsan to find such issues in my code, and
this would not really work if signed overflow was defined
to wrap.

...
> > > Hey, some more googling on my part seems to say that somebody saw the
> > > light, and it's likely getting fixed in newer C standard version.
> > 
> > I don't think it is changed. But C23 will require
> > integers to be repreeted using two's complement,
> > so there is a better chance to fix things
> > like this in the future.
> 
> If integers are guaranteed to be two's complement, then the only
> possible explanation for "left shift is undefined" goes away. So
> presumably the thing goes hand-in-hand with just making (the de-facto)
> negative shifting well-defined.

I think there is a fairy good chance to get this
changed.

> (Btw, shifting *by* a negative number - or by amounts bigger than the
> width of the type - is different. There are at least real reasons to
> complain about that, although I think "implementation defined" would
> still be hugely preferred over "undefined")
> 
> > The right people to complain to are the
> > compiler vendors, because they decide what
> > UB does in their implementation.
> 
> No. The bug was in the spec to begin with. The people to complain
> about are the incompetents that literally changed the C standard to be
> less well-specified.
>
> As far as I know, no actual compiler has ever made integer left-shift
> done anything bad. You'd literally have to do extra work for it, so
> there's no reason to do so.

I agree that the standard should be changed. But 
this example also shows that UB in the standard
does not inevitably causes the compilers to do
something stupid. It is still their choice.

> But because the standards committee messed up, the compiler writers
> *did* do the extra work to warn about the fact (for the trivial
> "negative constant" case - never mind that technically it's undefined
> for non-constants: that would have been too much work).

Compilers do *not* warn about a lot of undefined behavior 
(even where it would be easily possible and make perfect
sense). So why here?


Martin

Powered by blists - more mailing lists