Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp2338476pxm; Sun, 27 Feb 2022 18:41:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJxEkT+VwAYJT0ngNfzJjsXYlq7tW8K8ncheHF89zRiKC3RAAs3sMdXtOTdU+ybyk80R0XwB X-Received: by 2002:a05:6a00:887:b0:4f2:6d3f:5b53 with SMTP id q7-20020a056a00088700b004f26d3f5b53mr19501629pfj.21.1646016071353; Sun, 27 Feb 2022 18:41:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646016071; cv=none; d=google.com; s=arc-20160816; b=EhKzsze0TjbZRXjpkKHeyBH6ewDIV9ppnQDgzMo9exN7Lgt1b3fL4jWSQcUY+kWQ7E eIxCLx5OeldRil/6PfoQtu1WycY9D5savFTf9zEKXzXLrsI8/r6jHrfgwOQqGTbJVwea VYgrIFPLxEJ8Y9KghHMnA4iY8ZBQ/mGCJxjogNN1p2hX8lbh4NyA44Lg0GUOHRlQ30OJ 9slPcQ1TkUtNu29k0ev3JEsnM+49f4xHcKFLgYJhyDfVioHvjD2lrSBMJdqCDt1Y9ztG GXiqY4ilMeIbbhNkH0PqodN+HF7ogLbg260EntgwODw94eFZlr/f0N6PPd7DrfKhUsB7 FzaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Z4bnNwe7U2Vh4XIKAHcu6wdoajMLlbGI9CQD4DbPubI=; b=TiXERvHxyuGkNxC4m1Xdc1GfIYoAT3t/hfh3jjg/Cff9j2mPBRAyN30bSnWkGA9iwn nQKvz7ZMQJTTosQbbKGnCvR+wl/E08uWwrq9mftTHxoQHiyPQ31SORCoThk8qidXr5nC yqClDrx+PrrBVKyoar0DNMDr5/PtPfetPYscwElIC4f1MAAuHxMySTZzmfmgISXF/qcI 4WqAun5/LJGSALa65u0QgycOOOgrhPvYUUXR3zWkgnGDWVqwfBr92dUK86K8EN39hkby GRJ7OUmIyh+eiJ1WCPaKtLO+cY3BDpzqel0hU3z2H6bb/C2o+C9rmBFNxw8SzupIqGYY HbXg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=JIN504u2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n16-20020a170903111000b0014d9b821424si9089415plh.562.2022.02.27.18.40.55; Sun, 27 Feb 2022 18:41:11 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=JIN504u2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232097AbiB0WoA (ORCPT + 99 others); Sun, 27 Feb 2022 17:44:00 -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-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" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net 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