From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id A9D0C3858D1E for ; Tue, 13 Sep 2022 22:56:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A9D0C3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.93,313,1654588800"; d="scan'208";a="82811014" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 13 Sep 2022 14:56:17 -0800 IronPort-SDR: zrxBvTg4x7DNpyu/YfTfBvjVLxleD8Mq1xLXci9nXPE4uA3C4L8hOd69jkPtTD8v3dBjtMcNSw 860q2yu701I0L+ufa3WX8hhT6GPkuD9CnToHoEeCMaire0XNj7H4ZH3ql99QOw7Ww79pidMViK osqvpGzLbQQHkO/D4ZN1BwRvp9BcN23y/lQv1WHZSOWZY18bxLoG0xqU6BVS9CngOLZjk8t3Pr +p/MkYdmiPeT8c055n/nrd2CY7zsWN6wsgJSoNqZYheVuOjyDRoFZw6x1znPbAwMN+NAhzsL44 7FM= Date: Tue, 13 Sep 2022 22:56:11 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Alejandro Colomar CC: Paul Eggert , , Florian Weimer , JeanHeyd Meneide Subject: Re: [PATCH] inttypes.h: imaxabs(3): Implement as a macro In-Reply-To: Message-ID: References: <20220913151853.153311-1-alx.manpages@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-13.mgc.mentorg.com (139.181.222.13) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3111.2 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 13 Sep 2022, Alejandro Colomar wrote: > I don't understand the process by which gcc expands builtins. How does > exactly the suggested macro interfere with it? Is it because of the macro? > Or because of _Generic()? My point is that you already have to go out of your way to get a link-time reference to imaxabs - it will almost always have been expanded inline instead. Given that, your patch is adding extra complexity to address an issue that doesn't actually exist. > That is a workaround to the type being broken. The type can't widen, due to > ABI issues; for some time, the compiler provided __int128 as a limbo extension > that wouldn't be covered by intmax_t, and later ISO C just acknowledged the > fact and reworded the definition of intmax_t to be less of "the widest type" > and more or "a wide but not really widest type, so don't really trust it very > much". It is the type used for preprocessor arithmetic, for example. intmax_t was discussed at length in WG14, and while there was agreement on reducing its uses (hence the change to floating-point return types for fromfp functions, for example, see bug 28327), there was not agreement on any particular form of obsolescence. And it *is* useful in practice for printing types such as off_t or mode_t with no corresponding printf formats; those could just do with appropriate constraints to be no wider than intmax_t when a future POSIX revision is based on C2x. > If there's no hope in intmax_t, we should just mark the type as obsolescent, > and discard any idea of having a "widest" type at all. I don't think it's useful to try to rehash here discussions that were had at length in WG14. > Ahh, you anticipated part 2 of my plan. Deprecate "j", and add a new set of > macros PRIdMAX and the like. This type has it deserved. But I know those > macros aren't very well received, so it is just part 2. The actual direction is to move away from those macros (adding length modifiers for printing intN_t / int_leastN_t / int_fastN_t without needing to use such macros any more). -- Joseph S. Myers joseph@codesourcery.com