Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAHk-=wjtZG_0zjgVt0_0JDZgq=xO4LHYAbH764HTQJsjHTq-oQ@mail.gmail.com>
 <bd43bd47c8eaa4c22c1a1549cee66f7ef960b1fc.camel@med.uni-goettingen.de>
 <CAHk-=whFMxks63sfMQ-0_YO1GsTmoLfsO4ciMtoiCHNgaG_+GA@mail.gmail.com>
 <979af7ae9b7e8baf080ef6f8d42d48d7f5d2c5b4.camel@tugraz.at>
 <CANiq72k_PUBPVL1Fx4HLm_WO66RuSsi0oSsKRhssCYRNGbY84Q@mail.gmail.com> <dc52af7ebc044c94337e138f6e1ae807559b4825.camel@tugraz.at>
In-Reply-To: <dc52af7ebc044c94337e138f6e1ae807559b4825.camel@tugraz.at>
From:   Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Mon, 28 Feb 2022 14:49:57 +0100
Message-ID: <CANiq72mcuXDRM-xMDPuL7uDLUfXDhARTBJJsVj4fnR15T1v=TA@mail.gmail.com>
Subject: Re: [RFC PATCH 03/13] usb: remove the usage of the list iterator
 after the loop
To:     Martin Uecker <uecker@tugraz.at>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Feb 28, 2022 at 8:08 AM Martin Uecker <uecker@tugraz.at> wrote:
>
> Technically, this is true but not really in practice. If signed
> overflow would be defined to wrap, then code would start to
> rely on it and detecting it becomes useless because there are
> too many false positives.  In your own small controlled code
> base it could work though.

Either code is written with signed overflow in mind, or not. That is
what actually matters for detection, not whether it is UB in the
standard or not.

If a project starts relying on overflow wrapping, then they are taking
the same stance as projects that already rely on `-fwrapv`. That is
their choice, same as today.

But making it non-UB in the standard does not force a project to
consider it "not an error", which is what actually matters for being
able to use UBSan effectively or not.

In fact, if you are just concerned about detectability or `-fwrapv`
being the wrong default, there is still a way out without keeping it
UB: we could consider it an error (thus people is not encouraged to
rely on it), yet not UB. That is what Rust does, and why I suggested
the past exploring the move of some existing UB in C into an
"erroneous behavior, yet defined" area.

And, for the cherry on top, if users had a way to write exactly what
they mean (per operation or per type), then we can flag exactly the
cases that are not intentional, and users can still use unchecked
operations for performance sensitive code, etc.

Cheers,
Miguel