From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2CD4C433FE for ; Sun, 27 Feb 2022 22:43:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232101AbiB0WoB (ORCPT ); Sun, 27 Feb 2022 17:44:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33796 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232093AbiB0Wn6 (ORCPT ); Sun, 27 Feb 2022 17:43:58 -0500 Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88A9A3EB9F; Sun, 27 Feb 2022 14:43:21 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id q4so8758400ilt.0; Sun, 27 Feb 2022 14:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z4bnNwe7U2Vh4XIKAHcu6wdoajMLlbGI9CQD4DbPubI=; b=JIN504u2qQKThwiQ0dRzJl4Q1JGJc/rswp3AoRX7y2BC/ZNBM+/cn7UAXV99gtQ16s bBgiUUvet/5oYcL8u0Hi8FS7T8KhouECYUL2WVPC82JuOoW76dUOKv8DpZGCwarRcdAs YBoA0VY19lGkuUfWuBYiYK05rtybnWFusXwQO7BYx8juikiLo0cQZJqWugmOW9uEBZX8 OmtnKMihq4nmXhNnUt0dY147hFrkej9Ajnb7LSa126wnESmFZJmsoT+JikLlewrLrhoB UIoRV/+8eGUCWoNst8NVdZ62gnltE4xDzI1dLXochfsNXL8g+ondEc5FoBV4alw6CBf1 3iJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z4bnNwe7U2Vh4XIKAHcu6wdoajMLlbGI9CQD4DbPubI=; b=6W1DmWmGvK27dlobVD8EK4kyxAkjhKz9rcllK0AKPFybHPE4uGfj/B0sYHWsforCaZ KqQM8sVGV6+IeirjaMelSN4vmQewEZ6T3fT9DS4LatUkd8aWA+s7oMXS0vUQRMBeLtwg Eo1Ds0GvnDrUIfOI+EWI9VKJ3y6As/uBlFlweMQoepE5XdpNTP+SDcQnSLdbcLbC5Fbj VmDsb2nJxWX5KLiJTzPmVYW2tzt3pphN6wdAj1JYIfDhWa2rf8GVeedD/YxQU4O0ZmTB yP76f9MEQdVIKT0IuDzfxLZrhJ4J0ODrcualT7b5kp5gzNyntDOhZK2jCCDCLTopwDzt HppA== X-Gm-Message-State: AOAM533yuxNGDtKWAYJYuxlY4+l3nyJZgjwkw4RTCs7DVHSVtqErcFeD FsgAoGJbsDpjE+sH/hVx6gI4vGAv9lca6CejHOE= X-Google-Smtp-Source: ABdhPJx+SeevTo5vtSZhGvvpVA1ddy2bLL8U09bLcO/C5jYWsYcKNU24IfCWMR7ECyUwpgphUUaEuawHmtZKNIZFiMg= X-Received: by 2002:a05:6e02:b24:b0:2be:88f8:c4ed with SMTP id e4-20020a056e020b2400b002be88f8c4edmr16277966ilu.72.1646001800972; Sun, 27 Feb 2022 14:43:20 -0800 (PST) MIME-Version: 1.0 References: <6DFD3D91-B82C-469C-8771-860C09BD8623@gmail.com> <20220226124249.GU614@gate.crashing.org> <20220227010956.GW614@gate.crashing.org> <7abf3406919b4f0c828dacea6ce97ce8@AcuMS.aculab.com> <20220227113245.GY614@gate.crashing.org> <20220227201724.GZ614@gate.crashing.org> In-Reply-To: <20220227201724.GZ614@gate.crashing.org> From: Miguel Ojeda Date: Sun, 27 Feb 2022 23:43:09 +0100 Message-ID: Subject: Re: [RFC PATCH 03/13] usb: remove the usage of the list iterator after the loop To: Segher Boessenkool Cc: David Laight , Arnd Bergmann , Linus Torvalds , Jakob , Linux Kernel Mailing List , linux-arch , Greg Kroah-Hartman , Thomas Gleixner , Andy Shevchenko , Andrew Morton , Kees Cook , Mike Rapoport , "Gustavo A. R. Silva" , Brian Johannesmeyer , Cristiano Giuffrida , "Bos, H.J." Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Feb 27, 2022 at 9:19 PM Segher Boessenkool 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