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