From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id 876D6384841A for ; Tue, 4 May 2021 19:59:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 876D6384841A Received: by mail-wr1-x433.google.com with SMTP id d11so10694191wrw.8 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=BczcqlBAqrec4HSTjsMhHVXdzKf7+mpM9Ah38lAqgIuA9wW0FFfqdOyYR/ORZcN9vF D68WqT4ccUkqUK8a+7NS0yIHwPvYSRqHOd1NXNn4JmSOSHE27T5BkVSKl/Mf+Xu8Umxf spP40rsq9pfepirAAO1k+I6racr0z1su7n0eoUFA/K6OwqF4ATdnkoCSDR4ovsPGmaKK BW4A3ZXJqhDEP2osOwrulL++17FJilc9IjcYWjYgh+o80t0pmiL5tPFnT70W/lXhSmYJ OxcqdyhD/rmz9TC/g8ulfU3+faIRBdwmbTs+OlBHydgGdqRQqA2l5IzQQInrDMwyUVQH pADg== X-Gm-Message-State: AOAM5303f2zTd9GO+abzKLH5C1ZBEA6HTg1XQr55iXtRKxDyd03LxFsX H/V9d5dZNqzShgMADQfEvkg= 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=-3.4 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=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 19:59:13 -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/