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-=wg1RdFQ6OGb_H4ZJoUwEr-gk11QXeQx63n91m0tvVUdZw@mail.gmail.com>
 <6DFD3D91-B82C-469C-8771-860C09BD8623@gmail.com> <CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com>
 <CAHk-=wgLe-OSLTEHm=V7eRG6Fcr0dpAM1ZRV1a=R_g6pBOr8Bg@mail.gmail.com>
 <20220226124249.GU614@gate.crashing.org> <CAK8P3a2Dd+ZMzn=gDnTzOW=S3RHQVmm1j3Gy=aKmFEbyD-q=rQ@mail.gmail.com>
 <20220227010956.GW614@gate.crashing.org> <7abf3406919b4f0c828dacea6ce97ce8@AcuMS.aculab.com>
 <20220227113245.GY614@gate.crashing.org> <CANiq72m28WrjVHkcg5Y0LDa51Ur4OCpFbGdcq+v4gqiC0Wi6zg@mail.gmail.com>
 <20220227201724.GZ614@gate.crashing.org>
In-Reply-To: <20220227201724.GZ614@gate.crashing.org>
From:   Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Sun, 27 Feb 2022 23:43:09 +0100
Message-ID: <CANiq72nbLHvHX4Nk3oGutL=y3MghrFHs6HsmqN8HA8XwSv-4Ow@mail.gmail.com>
Subject: Re: [RFC PATCH 03/13] usb: remove the usage of the list iterator
 after the loop
To:     Segher Boessenkool <segher@kernel.crashing.org>
Cc:     David Laight <David.Laight@aculab.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Jakob <jakobkoschel@gmail.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-arch <linux-arch@vger.kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Kees Cook <keescook@chromium.org>,
        Mike Rapoport <rppt@kernel.org>,
        "Gustavo A. R. Silva" <gustavo@embeddedor.com>,
        Brian Johannesmeyer <bjohannesmeyer@gmail.com>,
        Cristiano Giuffrida <c.giuffrida@vu.nl>,
        "Bos, H.J." <h.j.bos@vu.nl>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sun, Feb 27, 2022 at 9:19 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> Requiring to annotate every place that has UB (or *can* have UB!) by the
> user is even less friendly than having so much UB is already :-(

Sure, but I did not suggest to annotate every place -- at least not in C.

What I said is that in cases like your division by zero example, there
is no one-fits-all solution. For instance, for integer arithmetic,
leaving the choice (e.g. wrapping, saturating, unchecked...) to the
user is a better approach.

> You need a VM like Java's to get even *close* to that.  This is not the
> C target: it is slower than wanted/expected, it is hosted instead of
> embedded, and it comes with a whole host of issues of its own.  One of
> the strengths of C is its tiny runtime, a few kB is a lot already!
>
> I completely agree that if you design a new "systems" language, you want
> to have much less undefined behaviour than C has.  But it is self-
> delusion to think you can eradicate all (or even most).

Nobody is suggesting to remove "all UB" in that sense or to use
VM-supported languages.

However, you can """eradicate all UB""" in a sense: you can offer to
write most code in a subset that does not allow any potential-UB
operations. This can even be "all" code, depending on how you count
(e.g. all application code).

Obviously, you still need the unchecked operations to implement the
safe APIs. This is why I mentioned them.

> And there are much bigger problems in any case!  If you think that if
> programmers could no longer write programs that invoke undefined
> behaviour they will write much better programs, programs with fewer
> serious functionality or security problems, even just a factor of two
> better, well...

Actually, according to several reports from Google, Microsoft, etc.,
it _is_ the biggest problem (~70%) when talking about security bugs.

So it is a good bet that it will translate into "better" programs, at
least on that axis, unless it is showed that removing UB somehow
increases the rate of other errors.

As for functionality problems, there are several ways to improve upon
C too, though it is harder to show data on that.

Cheers,
Miguel