From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) by sourceware.org (Postfix) with ESMTPS id 13C243857C71 for ; Fri, 2 Oct 2020 23:44:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 13C243857C71 Received: by mail-wm1-x344.google.com with SMTP id y15so3307949wmi.0 for ; Fri, 02 Oct 2020 16:44:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+JoIdcbY98ViLUA523Kk7PRiBhSdBpniG0/GR6tV1Lo=; b=EwmJhn6iZagVu791GOGkeLT8uYKT7PuW0ew1FrcRu6AX9+IwDD1//CTSCy9Hh9r4HR W9qYzk778h1oxhTaXFv3dueCtnUPrDvHsctxwsLzK16vl0zAXOQ5PnM4EPWcKoyAUfp6 ZbxbnvRirD8Itq9SwH0O8XVVdr+6AaCPtqflNsBmOKsyEpjhyvM4x/JHNdaG/cbs2YYJ IxTUYdcKwyQWEZbqgmhvbIguoLp6xOOXw5XYTY0BSYuZU4b80xCMs+wwJqs9dCNCV6Cm bzXXtoUr9GdX1pbXsXdmEMYvrmhEuzqdDjSqXaMMd8SI0JK5ivl7LSyb8Tv3y+90gTBt G41A== X-Gm-Message-State: AOAM531c3TaK3zsFJN+v0wAP2b+UAS6giR/Ntv/Xra4eQBlnibdzch23 eaZ8PxVOdH3MDYXvY0ej4FA= X-Google-Smtp-Source: ABdhPJytOEZ8r7tR6OT+5kyDg10YrvEXQ6rfJvQjkp/h3jf50rkJJJn73KwYYUhnzdcn+/pa5B3bHg== X-Received: by 2002:a7b:cf27:: with SMTP id m7mr5185367wmg.74.1601682277180; Fri, 02 Oct 2020 16:44:37 -0700 (PDT) Received: from [192.168.1.143] ([170.253.60.68]) by smtp.gmail.com with ESMTPSA id v4sm3247646wmg.35.2020.10.02.16.44.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Oct 2020 16:44:36 -0700 (PDT) From: Alejandro Colomar Subject: Re: [PATCH 1/4] system_data_types.7: Add '__int128' To: Paul Eggert Cc: Florian Weimer , Alejandro Colomar via Libc-alpha , linux-man@vger.kernel.org, gcc-patches@gcc.gnu.org, mtk.manpages@gmail.com References: <20201001163443.106933-1-colomar.6.4.3@gmail.com> <20201001163443.106933-2-colomar.6.4.3@gmail.com> <87eemg97ew.fsf@oldenburg2.str.redhat.com> <936422e4-d292-d435-6c3c-333b924b8ad0@cs.ucla.edu> Message-ID: <1f1430df-4bca-5cb4-1fc9-ae24c6a355bf@gmail.com> Date: Sat, 3 Oct 2020 01:44:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <936422e4-d292-d435-6c3c-333b924b8ad0@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, 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: Fri, 02 Oct 2020 23:44:39 -0000 Hi Paul, On 2020-10-02 22:19, Paul Eggert wrote: > On 10/2/20 1:03 PM, Alejandro Colomar wrote: >> I know it's not in stdint, >> but I mean that it behaves as any other stdint type. With caveats, of course. > > It doesn't. There's no portable way to use scanf and printf on it. I didn't need to. Yes that's a problem. It may be possible to write a custom specifier for printf, but I didn't try. I wrote one for printing binary, and it's not that difficult. If you really need it, this might help: https://github.com/alejandro-colomar/libalx/blob/d193b5648834c135824a5ba68d0ffcd2d38155a8/src/base/stdio/printf/b.c > You can't reliably convert it to intmax_t. Well, intmax_t isn't really that useful. I see it more like a generic type, than an actual type. I guess you could have typedef __int128 intwidest_t; if you find it's useful to you. > It doesn't have the associated _MIN and _MAX macros > that the stdint types do. It's a completely different animal. Those are really easy to write. For my use cases, they have been enough. These might be useful to you: #define UINT128_C(c) ((uint128_t)c) #define INT128_C(c) (( int128_t)c) #define UINT128_MAX ((uint128_t)~UINT128_C(0)) #define INT128_MAX (( int128_t)(UINT128_MAX >> 1)) #define INT128_MIN (( int128_t)(-INT128_MAX - 1)) > > If all you need are a few bit-twiddling tricks on x86-64, it should > work. But watch out if you try to do something fancy, like multiply or > divide or read or print or atomics. There's a good reason it's excluded > from intmax_t. I know, they aren't perfect. But they are still very useful, and don't see a good reason to not document them. Cheers, Alex