From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-4.7 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, PDS_RDNS_DYNAMIC_FP,RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id D3BAF1F953 for ; Fri, 3 Dec 2021 12:33:02 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0FB62385842B for ; Fri, 3 Dec 2021 12:33:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0FB62385842B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1638534782; bh=tpGZcD4nIKwqnuNHKHO0TBkz7hc0UrH6GNojNQbNLKw=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=Bu8TFwjA7csZiDrSV0oPBw+lbMs0qAT9QPHvkvr1Q8zYu/R02zi5qqLnewz2aWEa5 krzBaxJeXkWvsaOeY5Hablbzj7ycP8DoEUAMmG0IBt0DpUPAaDEcv8Hw0uMiHUUJI7 qC0SJ0j9JjIjKM54i2gRw8CEJMYXyIvTBuOUiJi4= Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) by sourceware.org (Postfix) with ESMTPS id D0B7A3858D28 for ; Fri, 3 Dec 2021 12:32:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D0B7A3858D28 Received: by mail-qv1-xf2e.google.com with SMTP id m17so2549906qvx.8 for ; Fri, 03 Dec 2021 04:32:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=tpGZcD4nIKwqnuNHKHO0TBkz7hc0UrH6GNojNQbNLKw=; b=h2rmmSwCBgpBqy6qvmvRUX4lZUA3CoZ8d36ENnS79+QF989FqbUGFkJCuYb/ME5DbY xoZZABU/HIpGuOe06JbZmr0C9YYJpsMjVsxOzJRyz+B7W1EwqjiVTeKnVW7xqo5DlGRi ijd+lOkmID8dzJLMehzRegPtK4SY3hgfEzHXP4EOJjxFpjaCxIzQ3tGof3HztJU2K3rr 0/vbExyNrwlV5f0Rx3iyZU1qGk1zyDNGr7JEhLuZ0y6oJsU6P9B7/I68bbgwb8BNJlkK HRgZRRqTPjwe4X7GFN2jPD9a3i3GFjFSyu/6KWywgAFGAseh7WBj9C+nW6DVBzuiozM6 AVEQ== X-Gm-Message-State: AOAM5328ZlYX8s9XRIm4sgmaSjFxIjhZYuWm6xE6DhfkHVGHSrxa+q47 Rpi/iy1tUontMipEt8qNSFgHBQ== X-Google-Smtp-Source: ABdhPJzaCgHrIbHSQbI0Sq3nOtRXTwg7hBaKyrlCC9ErC+zf+wgn72iYAl0CHvgkGMkfZn4Bi4B5jQ== X-Received: by 2002:a05:6214:4007:: with SMTP id kd7mr18672354qvb.52.1638534758304; Fri, 03 Dec 2021 04:32:38 -0800 (PST) Received: from ?IPV6:2804:431:c7cb:30f8:f5d6:4b6d:fe6a:d565? ([2804:431:c7cb:30f8:f5d6:4b6d:fe6a:d565]) by smtp.gmail.com with ESMTPSA id h22sm2258645qtb.86.2021.12.03.04.32.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Dec 2021 04:32:37 -0800 (PST) Message-ID: <0864bd62-7a93-106d-8a36-23dd72a7ab58@linaro.org> Date: Fri, 3 Dec 2021 09:32:34 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: [PATCH] uapi: Make __{u,s}64 match {u,}int64_t in userspace Content-Language: en-US To: Zack Weinberg , Rich Felker References: <20211202153422.GH7074@brightrain.aerifal.cx> <20211202232954.GI7074@brightrain.aerifal.cx> <855a47d1-a89c-bbc8-7ddd-b89104c6138a@linaro.org> <9d24f699-386a-4881-b09a-ebd747310187@www.fastmail.com> In-Reply-To: <9d24f699-386a-4881-b09a-ebd747310187@www.fastmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: , From: Adhemerval Zanella via Libc-alpha Reply-To: Adhemerval Zanella Cc: linux-arch@vger.kernel.org, linux-api@vger.kernel.org, libc-alpha@sourceware.org, linux-kernel@vger.kernel.org, ltp@lists.linux.it Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 02/12/2021 21:10, Zack Weinberg wrote: > On Thu, Dec 2, 2021, at 6:43 PM, Adhemerval Zanella via Libc-alpha wrote: >> On 02/12/2021 20:29, Rich Felker wrote: >>> On Thu, Dec 02, 2021 at 10:34:23AM -0500, Rich Felker wrote: >>>> On Mon, Nov 22, 2021 at 10:19:59PM +0000, Zack Weinberg via Libc-alpha wrote: >>>>> On Mon, Nov 22, 2021, at 4:43 PM, Cyril Hrubis wrote: >>>>>> This changes the __u64 and __s64 in userspace on 64bit platforms from >>>>>> long long (unsigned) int to just long (unsigned) int in order to match >>>>>> the uint64_t and int64_t size in userspace. >>>>> .... >>>>>> + >>>>>> +#include >>>>>> + >>>>>> /* >>>>>> - * int-ll64 is used everywhere now. >>>>>> + * int-ll64 is used everywhere in kernel now. >>>>>> */ >>>>>> -#include >>>>>> +#if __BITS_PER_LONG == 64 && !defined(__KERNEL__) >>>>>> +# include >>>>>> +#else >>>>>> +# include >>>>>> +#endif >>>>> >>>>> I am all for matching __uN / __sN to uintN_t / intN_t in userspace, but may I suggest the technically simpler and guaranteed-to-be-accurate >>>>> >>>>> /* >>>>> - * int-ll64 is used everywhere now. >>>>> + * int-ll64 is used everywhere in kernel now. >>>>> + * In user space match . >>>>> */ >>>>> +#ifdef __KERNEL__ >>>>> # include >>>>> +#elif __has_include () >>>>> +# include >>>>> +typedef __int8_t __s8; >>>>> +typedef __uint8_t __u8; >>>>> +typedef __int16_t __s16; >>>>> +typedef __uint16_t __u16; >>>>> +typedef __int32_t __s32; >>>>> +typedef __uint32_t __u32; >>>>> +typedef __int64_t __s64; >>>>> +typedef __uint64_t __u64; >>>>> +#else >>>>> +# include >>>>> +typedef int8_t __s8; >>>>> +typedef uint8_t __u8; >>>>> +typedef int16_t __s16; >>>>> +typedef uint16_t __u16; >>>>> +typedef int32_t __s32; >>>>> +typedef uint32_t __u32; >>>>> +typedef int64_t __s64; >>>>> +typedef uint64_t __u64; >>>>> +#endif >>>>> >>>>> The middle clause could be dropped if we are okay with all uapi >>>>> headers potentially exposing the non-implementation-namespace names >>>>> defined by . I do not know what the musl libc equivalent >>>>> of is. >>>> >>>> We (musl) don't have an equivalent header or __-prefixed versions of >>>> these types. >>>> >>>> FWIW I don't think stdint.h exposes anything that would be problematic >>>> alongside arbitrary use of kernel headers. >>> >>> Also, per glibc's bits/types.h: >>> >>> /* >>> * Never include this file directly; use instead. >>> */ >>> >>> it's not permitted (not supported usage) to #include . >>> So I think the above patch is wrong for glibc too. As I understand it, >>> this is general policy for bits/* -- they're only intended to work as >>> included by the libc system headers, not directly by something else. >> >> You are right, the idea is to allow glibc to create and remove internal headers. > > As a general rule yes, but we could make a deal that some specific bits headers are permanent API for use by things like this. They probably should be less of a dumping ground than bits/types.h though. I really don't think adding such constraints really would improve the project in long term, we already have issues about the need to support some internal symbols that were exported by accident.