Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp2177037pxm; Sun, 27 Feb 2022 13:39:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJw1Gd2EpDxWLVFCpJjt0Gsh3WyPMdPzAQedAqgEEdIOMuSW0EXbkIhWXRhtz1cWb4w4Gibv X-Received: by 2002:a17:902:e88d:b0:150:f47:2496 with SMTP id w13-20020a170902e88d00b001500f472496mr16919115plg.12.1645997972693; Sun, 27 Feb 2022 13:39:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645997972; cv=none; d=google.com; s=arc-20160816; b=p3M6zqJhmTU3nV1G8CHMrt03mfEswf2VUqTdCsavnWAowAJ2LZtWJlhyR7gZ3DTZqY 77P4pvPRsw/9UXlOljHlto8w0VqcwR7yn6Mbgw2MUY3CCNOhcjVfII4vyR+lWmJ+IMc2 bU7rzRJ+jLP2br12PLGV1MV7/em98W7ht9LLdR41NpQ1HoYvpAzyI+qT7Gsf1VNxrNuP uoXrne8bF76CPl6Ho0GstmfYRQkoFAoO3jbSHQRt651WFg0H71T75+hX5gxKlG4HzsOq ro+b8NMaKVsvnsZ9z9kHG/gOGgwG1b5OPgyOsGuMbXuD78cSNySv9vdkqMFcEZWIwmcL utqg== 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=eSHr3nTbnOhAHHvD9gcRuzb7Z+l/28mCvr6FBYKx3Jg=; b=lgA68PtDPwMBM5gBq7nSdEmG1EWLlz5Ew4RURYd+JGv4Eip2BC2b/2oL0YDTUrxgTY 6Tr1ibQfpp44Er3g3ApcHuQ2sNkfc+12l9SKGa1HEJeuCU3m67LAY/2o7g9YsYxqsE1X Ai1ewTYX4gwS5KTG3XTwe+mFlHxZ2ix3ht7iFjdikWjPSno7zDobu37mW6TNWppoDtrb jZ5HHqut1whBr3o5jwp62NhlzXAP1klJb5+78lrfp+1VO2EXOp1bjUNllOBNzavkZ2tV JOovvb+KM30KsJ2S3Tk5SZqa7xnhVoLiUllhahWzVr6nCOCT/UAEsdQ7aPkssyFzLedm HTeg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=cz5eFf01; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b17-20020a17090a8c9100b001bd0a56f8f8si5881384pjo.85.2022.02.27.13.39.17; Sun, 27 Feb 2022 13:39:32 -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=@linux-foundation.org header.s=google header.b=cz5eFf01; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230336AbiB0VGI (ORCPT + 99 others); Sun, 27 Feb 2022 16:06:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229519AbiB0VFr (ORCPT ); Sun, 27 Feb 2022 16:05:47 -0500 Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D924B28E09 for ; Sun, 27 Feb 2022 13:05:09 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id y24so18186519lfg.1 for ; Sun, 27 Feb 2022 13:05:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eSHr3nTbnOhAHHvD9gcRuzb7Z+l/28mCvr6FBYKx3Jg=; b=cz5eFf016k8zCL008IYZ3R+cQOb1ZLSrvaH9TuTcK33seJTFNea2L6f1v/f6Q3Jdy5 NFzHYU5pSElShwGf1W+/92sNTVXqYzefCxivdNt4eI+wHqItKzpbafgD6tz2sVbC8Sed xc12WaBJOXbs9pLvKFyf1hV8Upui8mPhoKcY4= 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=eSHr3nTbnOhAHHvD9gcRuzb7Z+l/28mCvr6FBYKx3Jg=; b=XWZzMu1Zz8C+DfKW66cC6Zs7K/jgcf2nNJ+f+Nq20kMt0kPKjqiIczDxlRP+KzOd69 cAnuvLBk9FNeWyA1xrzNNkH2iLPnrlDGfq0xiV8qE/uiMrjoqwtfN8Uu9e5pBxvB9Mb8 j9o7wAsJfq7itZhJRjuWfK8pNMTSU9dbCheOVYVwG/prGi/y9wCSM2xTiYV8G6xvWQ+p w2sdd+4dw8tKjDIVbTpqO9Ng/awgyhzE9WLJopht7ndX5mJQ58VZnDvg79ZQS8J75tH+ 3vJfVwW9HZd/slT76h5aY1p2m7g8yzgzogis4gZY2Urh/lTNtDymv4Mscm3YTqQQulWj 2MNw== X-Gm-Message-State: AOAM530xGIgK7lnXW3olTqK4ySykirmNemLwTmuuOt6C3L6C3GNynjv7 XrIOWXdlue+tnHhQRhse2zfmga582ygK+6Dvbqs= X-Received: by 2002:a05:6512:6d3:b0:440:c1d0:7fec with SMTP id u19-20020a05651206d300b00440c1d07fecmr11150955lff.674.1645995907638; Sun, 27 Feb 2022 13:05:07 -0800 (PST) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com. [209.85.208.177]) by smtp.gmail.com with ESMTPSA id n22-20020a195516000000b004433dd2a853sm733669lfe.294.2022.02.27.13.05.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Feb 2022 13:05:05 -0800 (PST) Received: by mail-lj1-f177.google.com with SMTP id p20so14865131ljo.0 for ; Sun, 27 Feb 2022 13:05:04 -0800 (PST) X-Received: by 2002:a2e:924d:0:b0:246:370c:5618 with SMTP id v13-20020a2e924d000000b00246370c5618mr12174195ljg.358.1645995904456; Sun, 27 Feb 2022 13:05:04 -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: Linus Torvalds Date: Sun, 27 Feb 2022 13:04:48 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 03/13] usb: remove the usage of the list iterator after the loop To: Segher Boessenkool Cc: Miguel Ojeda , David Laight , Arnd Bergmann , 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=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no 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 12:22 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 :-( Yeah, I don't think that's the solution. In fact, I don't think that's even practically the _issue_. Honestly, a lot of "undefined behavior" in C is quite often of the kind "the programmer knows what he wants". Things like word size or byte order issues etc are classic "undefined behavior" in the sense that the C compiler really doesn't understand them. The C compiler won't silently fix any silly behavior you get from writing files in native byte order, and them not working on other platforms. Same goes for things like memory allocators - they often need to do things that the standard doesn't really cover, and shouldn't even *try* to cover. It's very much a core example of where people do odd pointer arithmetic and change the type of pointers. The problem with the C model of "undefined behavior" is not that the behavior ends up being architecture-specific and depending on various in-memory (or in-register) representation of the data. No, those things are often very much intentional (even if in the case of byte order, the "intention" may be that the programmer simply does not care, and "knows" that all the world is little endian). If the C compiler just generates reliable code that can sanely be debugged - including very much using tools that look for "hey, this behavior can be surprising", ie all those "look for bad patterns at run-time", then that would be 100% FINE. But the problem with the C notion of undefined behavior is NOT that "results can depend on memory layout and other architecture issues that the compiler doesn't understand". No, the problem is that the C standards people - and compiler people - have then declared that "because this can be surprising, and the compiler doesn't understand what is going on, now the compiler can do something *else* entirely". THAT is the problem. The classic case - and my personal "beat a dead horse" - is the completely broken type-based aliasing rules. The standards people literally said "the compiler doesn't understand this, it can expose byte order dependencies that shouldn't be explained, SO THE COMPILER CAN NOW DO SOMETHING COMPLETELY INSANE INSTEAD". And compiler people? They rushed out to do completely broken garbage - at least some of them did. You can literally find compiler people who see code like this (very traditional, traditionally very valid and common, although): // Return the least significant 16 bits of 'a' on LE machines #define low_16_bits(x) (*(unsigned short *)&(x)) and say "oh, because that's undefined, I can now decide to not do what the programmer told me to do AT ALL". Note that the above wasn't actually even badly defined originally. It was well-defined, it was used, and it was done by programmers that knew what they were doing. And then the C standards people decided that "because our job isn't to describe all the architectural issues you can hit, we'll call it undefined, and in the process let compiler people intentionally break it". THAT is a problem. Undefined results are are often intentional in system software - or they can be debugged using smart tools (including possibly very expensive run-time code generation) that actively look for them. But compilers that randomly do crazy things because the standard was bad? That's just broken. If compilers treated "undefined" as the same as "implementation-defined, but not explicitly documented", then that would be fine. But the C standards people - and a lot of compiler people - really don't seem to understand the problems they caused. And, btw, caused for no actual good reason. The HPC people who wanted Fortran-style aliasing could easily have had that with an extension. Yes, "restrict" is kind of a crappy one, but it could have been improved upon. Instead, people said "let's just break the language". Same exact thing goes for signed integer overflow. Linus