From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 8822E3848421 for ; Tue, 4 May 2021 19:59:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8822E3848421 Received: by mail-wr1-x42f.google.com with SMTP id m9so10714676wrx.3 for ; Tue, 04 May 2021 12:59:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DrWNrfi+Ew4LFUqUpxDkLKZY4953siWYFeGLtwXjn7A=; b=nSF9pjByAK3Phxr+heZam1BA/71EWwKe1idTdJQNnGeCCSuYtiPgMD02oQWH3CAKGk mfp2mswgT/U5g7hLwmsJNF7TIWYi7KnBEijtVIDr7An7iE6ZYVC4+mZfOMwwLpJPjOFU sHtRL7sKQym45IUDNdvYZtEC9pqeM2ixZEp9NYVzafx8d4kvGO0JK4guQ2GyeKZx/PvD e+1oupzE+kETokBkvMczMoQX6DPjvW9b6ZU/M3PF+CAnc1lhY3WB2oVR3FMujGu2rzDM fVrLdvoATPshio9msKZajjaMmhXy5j3tC6JBFrsKKnYW1TZ7RmDyq0kNbaGYLp1QW96g MWpw== X-Gm-Message-State: AOAM533vw0nD3AUmgvK2B1CB1we9g1nmzkECPGb1DzlOPk1xFKJ02GX/ SDnwJPg6tYBL625B7dJlVCI= X-Google-Smtp-Source: ABdhPJx8/T5dui/MKJ9f8IBJbNOXe96bYqrulWjqjgmOC+4G26OcBLa/GwDB3uSESgK9l9w+4GTsZg== X-Received: by 2002:a05:6000:186f:: with SMTP id d15mr33984740wri.400.1620158349706; Tue, 04 May 2021 12:59:09 -0700 (PDT) Received: from [192.168.0.237] ([170.253.36.171]) by smtp.gmail.com with ESMTPSA id x17sm3426158wmc.11.2021.05.04.12.59.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 May 2021 12:59:09 -0700 (PDT) Subject: Re: [RFC v2] bpf.2: Use standard types and attributes To: Florian Weimer Cc: Zack Weinberg , Greg KH , Daniel Borkmann , Alexei Starovoitov , "Michael Kerrisk (man-pages)" , linux-man , LKML , glibc , GCC , bpf , Joseph Myers , David Laight References: <20210423230609.13519-1-alx.manpages@gmail.com> <20210504110519.16097-1-alx.manpages@gmail.com> <69fb22e0-84bd-47fb-35b5-537a7d39c692@gmail.com> <6740a229-842e-b368-86eb-defc786b3658@gmail.com> <87r1imgu5g.fsf@oldenburg.str.redhat.com> From: "Alejandro Colomar (man-pages)" Message-ID: <0d9a795a-7c6a-3889-af31-2223dc216d15@gmail.com> Date: Tue, 4 May 2021 21:59:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <87r1imgu5g.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 19:59:11 -0000 Hi Florian, On 5/4/21 9:45 PM, Florian Weimer wrote: > * Alejandro Colomar: > >> The thing is, in all of those threads, the only reasons to avoid >> types in the kernel (at least, the only explicitly >> mentioned ones) are (a bit simplified, but this is the general idea of >> those threads): >> >> * Possibly breaking something in such a big automated change. >> * Namespace collision with userspace (the C standard allows defining >> uint32_t for nefarious purposes as long as you don't include >> . POSIX prohibits that, though) >> * Uglier > > __u64 can't be formatted with %llu on all architectures. That's not > true for uint64_t, where you have to use %lu on some architectures to > avoid compiler warnings (and technically undefined behavior). There are > preprocessor macros to get the expected format specifiers, but they are > clunky. I don't know if the problem applies to uint32_t. It does > happen with size_t and ptrdiff_t on 32-bit targets (both vary between > int and long). > Hmmm, that's interesting. It looks like Linux always uses long long for 64 bit types, while glibc uses 'long' as long as it's possible, and only uses 'long long' when necessary. Assignment is still 100% valid both ways and binary compatibility also 100% (AFAIK), given they're the same length and signedness, but pointers are incompatible. That's something to note, even though in this case there are no pointers involved, so no incompatibilities. Maybe the kernel and glibc could use the same rules to improve compatibility, but that's out of the scope of this. Thanks, Alex -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/