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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9B3D1C4727E for ; Thu, 1 Oct 2020 17:31:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4F71120872 for ; Thu, 1 Oct 2020 17:31:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732407AbgJARbd (ORCPT ); Thu, 1 Oct 2020 13:31:33 -0400 Received: from esa3.mentor.iphmx.com ([68.232.137.180]:32876 "EHLO esa3.mentor.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732287AbgJARbc (ORCPT ); Thu, 1 Oct 2020 13:31:32 -0400 IronPort-SDR: Vjoul8mRRCjAcWBd2jm4PIEhaKlu17jM4VcBeAgjKer6+Td8w0t28gjI2S8FrGf0wwkPQCu+QN uc8Yjf7kxf/ZEnmGCQTf0cyCh3dRgh5ZXVZSpc9/AfAQGQBW3YK65LLQCWNH/f08pzrqdoj7SS SHFI1tktb/zxYLkH/MU/DpUcu8c/N7XjRwnVgcddIHkP3dMZUhYqs7RnWrczn1UZihZCtflOx1 k4y9qeeJTl7LZOgzqblqgYzMcci9Jzjeg5MaWLshHX6OJ2Hfkm1OO+4/hMi8rhNVVk2BEj6sQX q/E= X-IronPort-AV: E=Sophos;i="5.77,324,1596528000"; d="scan'208";a="53473929" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 01 Oct 2020 09:31:32 -0800 IronPort-SDR: 5j0x1AUJ1eFEKRFBHttUzOIhb8BbpHGu6fJMt8JnSd2CD7HV75mezuxZOzoZC/C02GHTfNSSa+ TThh8BOXX7OM9d+xdaGKM0fIyqwV/I/gE3KcpoUw2eGO1T2uSnisHnp/1azeN3O/y6BB3TGYrd Foao/nUMACY7chgTgRWPOnpCRfpOhnSwWqeJVtliZr3dR4ifVthAABHyM53dH9qszHrmgaQnGj tIaIFG7u3+prGYtqIxpXdlAkJZCMM3nWOnNSKKJVfZtRb32XpATAR+QticorIMCS9HmyAEssSg GOA= Date: Thu, 1 Oct 2020 17:31:26 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Alejandro Colomar CC: Jonathan Wakely , "gcc@gcc.gnu.org" , linux-man , "Michael Kerrisk (man-pages)" Subject: Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128 In-Reply-To: <5ed7272e-1c81-d1f5-6a54-0fee4270199e@gmail.com> Message-ID: References: <5ed7272e-1c81-d1f5-6a54-0fee4270199e@gmail.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org On Thu, 1 Oct 2020, Alejandro Colomar via Gcc wrote: > Because 'intmax_t' has a bug > (actually I know GCC rejected the bug report, > but the problem is still there and users should be informed about this) > which is related to __int128. __int128 is not an integer type as defined by any existing version of ISO C, precisely because it's wider than intmax_t, and changing intmax_t would be a big ABI problem (involving new symbol versions for about 100 printf/scanf-related functions in glibc, 200 on platforms with multiple long double variants). See the proposed removal of intmax_t in C2x (accepted in principle at the first virtual Freiburg meeting, but so far without any wording accepted for any specific approach to removal regarding e.g. preprocessor arithmetic and other places depending on intmax_t). That removal would allow __int128 to be considered an extended integer type as defined by C2x and later (with int128_t typedef in , etc.), if desired. -- Joseph S. Myers joseph@codesourcery.com