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 A780AC28D13 for ; Thu, 25 Aug 2022 07:27:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237301AbiHYH1z (ORCPT ); Thu, 25 Aug 2022 03:27:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235610AbiHYH1u (ORCPT ); Thu, 25 Aug 2022 03:27:50 -0400 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 15AA2DFA9 for ; Thu, 25 Aug 2022 00:27:48 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id m1so43998edb.7 for ; Thu, 25 Aug 2022 00:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=/oj50hsl8kbfl2r5TD7WwWtw83gdRut5PdToYGpC4Ik=; b=Goy06y0aydlFdewFjaQoeuV6+94AF3G4Kd5MnBCFsRmAguUDtmTDpQb6gSDsC8v858 O/sDYoTbg6PSw67ijrEnRK2ZAHwB9YaQefNZl+U/92XlmmBmO0tImfXBiXc6OEXrm0Mk aFgclEQ/Wy3ZKJgW2dVbRAOlKaWpWn3UCrdcw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=/oj50hsl8kbfl2r5TD7WwWtw83gdRut5PdToYGpC4Ik=; b=pLnwnjc6sIaUOlpEJA0U564Fei3aSODUsPQM5E6LFmkKGkkha8YMXYRqglmjgxeGSF g+HzIHVkARHZIkaEcGqJd4H89qJeWsBQNdRVDezsxOjTUp/9VaEjv0xpIxN6SsU0XCGm r+YG8/ZQeE8GHla+eXw/ezpBdbFnM5qSTySswAHK0dUkMpLlVyPFL88mW7xand3miI+D jBObQcMio2xDTzbXEnUe5QN6v6okcHDbJFsFME2JLlIaj0A1+5twxVNo90+JW025IGOw OB7/vPUcDQRi8ehvwY/1nXpadBaBgm6wxTxYo9ykFyUL/JGELlFDgRrpgIGSQX5LFIfv nfoA== X-Gm-Message-State: ACgBeo0alPo5Ps1v1S9IA7lMk99OJdcjYtQ446O09DTkJSIU/EawDLVg /Kj24qo2Li1UB0sMW+B1xgyZUFn19BtsJ6bGxTM= X-Google-Smtp-Source: AA6agR4Ju5Ibev6QRdH5lLw0SVBunrsBbFTx68BXkY/SMBHpe49zFxDG3XBU91El7OZSKl2dud/DJA== X-Received: by 2002:a05:6402:5108:b0:447:592:7ba5 with SMTP id m8-20020a056402510800b0044705927ba5mr2081682edd.156.1661412466319; Thu, 25 Aug 2022 00:27:46 -0700 (PDT) Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com. [209.85.221.45]) by smtp.gmail.com with ESMTPSA id x24-20020aa7cd98000000b0044792480994sm1699206edv.68.2022.08.25.00.27.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Aug 2022 00:27:44 -0700 (PDT) Received: by mail-wr1-f45.google.com with SMTP id bs25so23463791wrb.2 for ; Thu, 25 Aug 2022 00:27:43 -0700 (PDT) X-Received: by 2002:a5d:6248:0:b0:222:cd3b:94c8 with SMTP id m8-20020a5d6248000000b00222cd3b94c8mr1385724wrv.97.1661412462666; Thu, 25 Aug 2022 00:27:42 -0700 (PDT) MIME-Version: 1.0 References: <20210423230609.13519-1-alx.manpages@gmail.com> <20220824185505.56382-1-alx.manpages@gmail.com> <87ilmgddui.fsf@oldenburg.str.redhat.com> In-Reply-To: <87ilmgddui.fsf@oldenburg.str.redhat.com> From: Linus Torvalds Date: Thu, 25 Aug 2022 00:27:26 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming To: Florian Weimer Cc: Greg Kroah-Hartman , Alejandro Colomar , Alexei Starovoitov , Alex Colomar , Alexei Starovoitov , linux-man , Daniel Borkmann , Zack Weinberg , LKML , glibc , GCC , bpf , LTP List , Linux API , linux-arch , David Laight , Joseph Myers , Cyril Hrubis , David Howells , Arnd Bergmann , Rich Felker , Adhemerval Zanella , Michael Kerrisk Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 24, 2022 at 11:41 PM Florian Weimer wrote: > > The justifications brought forward are just regurgitating previous > misinformation. If you do that, it's hard to take you seriously. Pot, meet kettle. > There is actually a good reason for using __u64: it's always based on > long long, so the format strings are no longer architecture-specific, [..] That's a small detail that yes, we've tried to avoid the absolute humongous mess that the C standard library has with their horrendous 'PRId*' mess, but honestly, it's just a tiny detail. The real issue is that we want to be able to control our own types, and our own names, and in the process have sometimes been able to standardize on types that makes it easier to just not have to deal with "oh, somebody picked 'int' on this architecture, and 'long' on this other, and they are both 32-bit types". We still have to deal with that for '[s]size_t', but that's such a standard legacy type that thankfully we have the whole '%zu/%zd' thing for that. And yes, sometimes we screw up even *though* we were the ones that picked the types, and we've had pointless differences where '__u64' could be 'unsigned long' on a 64-bit architecture, and 'unsigned long long' on a 32-bit one, and then we were able to fix our own little broken type system exactly because it was *OUR* little type system. So you are correct that then in the specific case of '__u64' we have been able to simply just standardize on 'unsigned long long' and make printf strings simpler. But you are wrong to think that that is somehow a special thing. It's not. It's very much all the same thing: we have types *we* control, and thanks to that we can do them the way *we* need them done, and can fix them when we made a silly mistake. In other words, it's the whole *point* of not ever using 'stdint.h' at all for those things. (It's also about avoiding the kinds of unholy things that happen in system header files. Have you ever *looked* at them? Christ. The amount of absolute crap you get from including in user space is scary) > You cannot avoid using certain ISO C names with current GCC or Clang, > however hard you try. You are now the one who is regurgitating complete mis-information. You do it so prettily, and with such weasel-wording, that I know you must be knowingly threading that fine line between "actively misleading" but trying to avoid "outright lying".. You say "certain ISO C names" to try to make it sound as if this was at all relevant to things like "uint32_t" and friends. But deep down, you know you're basically lying by omission. Because it's true that we have to know and care about things like 'size_t', which comes up for all the basic string.h functions. So yes, we have a very small set of types that we make sure matches the compiler notion of said types, and we carefully use things like typedef __kernel_ulong_t __kernel_size_t; and then we have our own 'stdarg.h which uses typedef __builtin_va_list va_list; that is explicitly the one that the compiler exposes with those double underscores exactly because even the compiler can't expose the "standard" name due to namespace issues. And no, NONE OF THOSE ARE USABLE IN THE UAPI HEADERS! And equally importantly, none of those have *anything* to do with the 'uint32_t' kind of names. The fact that yes, we care about what the compiler thinks "size_t" is (because we do want the compiler to do memset() for us) has absolutely *NOTHING* to do with uint32_t and . And I'm pretty sure you knew that, but you tried to make it sound like they were somehow all in the same boat. And yes, some drivers tend to actually use 'uint32_t' in the kernel, and we allow it, but they cannot be used by user interfaces. So a uapi file really *really* shouldn't ever use them. And no, we don't use "-ffreestanding" and friends - we actually have occasionally wanted and tried to do so just to make the boundary lines clearer, but then that will make gcc no longer do sane things for 'memcpy()'' and friends, so it's kind of a balancing act. > , , are compiler-provided headers that > are designed to be safe to use for bare-metal contexts (like in > kernels). Avoiding them is not necessary per se. We explicitly avoid them all. We historically used stdarg.h and stddef.h (but never stdint.h - there's absolutely _zero_ upside), but it was always a slight pain. So we simply bake our own, exactly because it's simply less painful than having to deal with possible system-provided ones. People do odd compiler things with host compilers, bad or odd installations of cross-build environments, it's just not worth the pain to deal with the "system header files" when they just don't provide any real value. Linus 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 picard.linux.it (picard.linux.it [213.254.12.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DA588C04AA5 for ; Thu, 25 Aug 2022 07:34:33 +0000 (UTC) Received: from picard.linux.it (localhost [IPv6:::1]) by picard.linux.it (Postfix) with ESMTP id 949BD3CA441 for ; Thu, 25 Aug 2022 09:34:31 +0200 (CEST) Received: from in-3.smtp.seeweb.it (in-3.smtp.seeweb.it [IPv6:2001:4b78:1:20::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by picard.linux.it (Postfix) with ESMTPS id EDBD43C3090 for ; Thu, 25 Aug 2022 09:34:20 +0200 (CEST) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by in-3.smtp.seeweb.it (Postfix) with ESMTPS id DE7981A0044C for ; Thu, 25 Aug 2022 09:34:19 +0200 (CEST) Received: by mail-ed1-x52f.google.com with SMTP id c93so254832edf.5 for ; Thu, 25 Aug 2022 00:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=/oj50hsl8kbfl2r5TD7WwWtw83gdRut5PdToYGpC4Ik=; b=Goy06y0aydlFdewFjaQoeuV6+94AF3G4Kd5MnBCFsRmAguUDtmTDpQb6gSDsC8v858 O/sDYoTbg6PSw67ijrEnRK2ZAHwB9YaQefNZl+U/92XlmmBmO0tImfXBiXc6OEXrm0Mk aFgclEQ/Wy3ZKJgW2dVbRAOlKaWpWn3UCrdcw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=/oj50hsl8kbfl2r5TD7WwWtw83gdRut5PdToYGpC4Ik=; b=qiOmWVBe3wVJFXY8NuvSkh2yQlAshzSZjtyNHGzU2qv8xa4SokKdIKhc0hHonSmiMF B3SXONkxN7Xsg/F1zoeRIfI6m11rl3KdFwcJg8AE62O4gYO3oiK1MpfxwdiQSgCXk1+h /Anzq3epyGdd0E6lZA/z4jbu0MWewyfoIg5TmgwUl8HUAueuzvklnU+q+Nugo/fnAHVe KCe0nDI7d8vfqs79BXJkxJzkM/4syD8xPHL4QpdtPTfcCV/+ZyKQ3a8c92PByGyAa7Hn iqpkaAL1n1A6hnUS6YgSJcIb172HJcVfpth5Cy2MQ2EAGfsNLqC9e51Lbn7+6ec8xptp YZjA== X-Gm-Message-State: ACgBeo2plX8OQMTC7xJn26YydKBAY5x5NeeCzDhNZBit6oMiMJUvR3it Tr9TP0A1/3sN6N2AGTKVW/FEcuXY8broKMEhyyA= X-Google-Smtp-Source: AA6agR6N+s2IyUDHeEf/dglT3byuUrs/PZmXXCROK3cvcSPQY/7uBnbRh/YBJZmbmJHEPmNOfAQBHg== X-Received: by 2002:a05:6402:43c4:b0:43b:c5eb:c9dd with SMTP id p4-20020a05640243c400b0043bc5ebc9ddmr2060793edc.402.1661412858921; Thu, 25 Aug 2022 00:34:18 -0700 (PDT) Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com. [209.85.218.53]) by smtp.gmail.com with ESMTPSA id t26-20020a50c25a000000b0043bbc9503ddsm4359334edf.76.2022.08.25.00.34.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Aug 2022 00:34:18 -0700 (PDT) Received: by mail-ej1-f53.google.com with SMTP id og21so312918ejc.2 for ; Thu, 25 Aug 2022 00:34:18 -0700 (PDT) X-Received: by 2002:a5d:6248:0:b0:222:cd3b:94c8 with SMTP id m8-20020a5d6248000000b00222cd3b94c8mr1385724wrv.97.1661412462666; Thu, 25 Aug 2022 00:27:42 -0700 (PDT) MIME-Version: 1.0 References: <20210423230609.13519-1-alx.manpages@gmail.com> <20220824185505.56382-1-alx.manpages@gmail.com> <87ilmgddui.fsf@oldenburg.str.redhat.com> In-Reply-To: <87ilmgddui.fsf@oldenburg.str.redhat.com> From: Linus Torvalds Date: Thu, 25 Aug 2022 00:27:26 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Florian Weimer X-Virus-Scanned: clamav-milter 0.102.4 at in-3.smtp.seeweb.it X-Virus-Status: Clean Subject: Re: [LTP] [PATCH v3] Many pages: Document fixed-width types with ISO C naming X-BeenThere: ltp@lists.linux.it X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Test Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alejandro Colomar , linux-man , Rich Felker , Alexei Starovoitov , David Howells , Alexei Starovoitov , Joseph Myers , linux-arch , Zack Weinberg , Daniel Borkmann , Alex Colomar , Michael Kerrisk , Arnd Bergmann , GCC , LTP List , glibc , Greg Kroah-Hartman , LKML , David Laight , Adhemerval Zanella , Linux API , bpf Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ltp-bounces+ltp=archiver.kernel.org@lists.linux.it Sender: "ltp" On Wed, Aug 24, 2022 at 11:41 PM Florian Weimer wrote: > > The justifications brought forward are just regurgitating previous > misinformation. If you do that, it's hard to take you seriously. Pot, meet kettle. > There is actually a good reason for using __u64: it's always based on > long long, so the format strings are no longer architecture-specific, [..] That's a small detail that yes, we've tried to avoid the absolute humongous mess that the C standard library has with their horrendous 'PRId*' mess, but honestly, it's just a tiny detail. The real issue is that we want to be able to control our own types, and our own names, and in the process have sometimes been able to standardize on types that makes it easier to just not have to deal with "oh, somebody picked 'int' on this architecture, and 'long' on this other, and they are both 32-bit types". We still have to deal with that for '[s]size_t', but that's such a standard legacy type that thankfully we have the whole '%zu/%zd' thing for that. And yes, sometimes we screw up even *though* we were the ones that picked the types, and we've had pointless differences where '__u64' could be 'unsigned long' on a 64-bit architecture, and 'unsigned long long' on a 32-bit one, and then we were able to fix our own little broken type system exactly because it was *OUR* little type system. So you are correct that then in the specific case of '__u64' we have been able to simply just standardize on 'unsigned long long' and make printf strings simpler. But you are wrong to think that that is somehow a special thing. It's not. It's very much all the same thing: we have types *we* control, and thanks to that we can do them the way *we* need them done, and can fix them when we made a silly mistake. In other words, it's the whole *point* of not ever using 'stdint.h' at all for those things. (It's also about avoiding the kinds of unholy things that happen in system header files. Have you ever *looked* at them? Christ. The amount of absolute crap you get from including in user space is scary) > You cannot avoid using certain ISO C names with current GCC or Clang, > however hard you try. You are now the one who is regurgitating complete mis-information. You do it so prettily, and with such weasel-wording, that I know you must be knowingly threading that fine line between "actively misleading" but trying to avoid "outright lying".. You say "certain ISO C names" to try to make it sound as if this was at all relevant to things like "uint32_t" and friends. But deep down, you know you're basically lying by omission. Because it's true that we have to know and care about things like 'size_t', which comes up for all the basic string.h functions. So yes, we have a very small set of types that we make sure matches the compiler notion of said types, and we carefully use things like typedef __kernel_ulong_t __kernel_size_t; and then we have our own 'stdarg.h which uses typedef __builtin_va_list va_list; that is explicitly the one that the compiler exposes with those double underscores exactly because even the compiler can't expose the "standard" name due to namespace issues. And no, NONE OF THOSE ARE USABLE IN THE UAPI HEADERS! And equally importantly, none of those have *anything* to do with the 'uint32_t' kind of names. The fact that yes, we care about what the compiler thinks "size_t" is (because we do want the compiler to do memset() for us) has absolutely *NOTHING* to do with uint32_t and . And I'm pretty sure you knew that, but you tried to make it sound like they were somehow all in the same boat. And yes, some drivers tend to actually use 'uint32_t' in the kernel, and we allow it, but they cannot be used by user interfaces. So a uapi file really *really* shouldn't ever use them. And no, we don't use "-ffreestanding" and friends - we actually have occasionally wanted and tried to do so just to make the boundary lines clearer, but then that will make gcc no longer do sane things for 'memcpy()'' and friends, so it's kind of a balancing act. > , , are compiler-provided headers that > are designed to be safe to use for bare-metal contexts (like in > kernels). Avoiding them is not necessary per se. We explicitly avoid them all. We historically used stdarg.h and stddef.h (but never stdint.h - there's absolutely _zero_ upside), but it was always a slight pain. So we simply bake our own, exactly because it's simply less painful than having to deal with possible system-provided ones. People do odd compiler things with host compilers, bad or odd installations of cross-build environments, it's just not worth the pain to deal with the "system header files" when they just don't provide any real value. Linus -- Mailing list info: https://lists.linux.it/listinfo/ltp