From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) by sourceware.org (Postfix) with ESMTPS id E151D3857C44 for ; Wed, 14 Sep 2022 19:03:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E151D3857C44 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=soasis.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=soasis.org Received: by mail-vk1-xa2e.google.com with SMTP id g85so2266039vkf.10 for ; Wed, 14 Sep 2022 12:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soasis.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=5u6WccQv02wGQwmPOCGRW8ANlKCyhwzyl3N76RvRkYA=; b=Td3UDWkfcuxbi+wJQ7yS/84I08sSD4xfT4c7hloVJ0dDn/OW++VE+tUzITWP7wP8Ns yX4roml+XqeNi0Xpz1N1etH5jyyLG3nBd2yU1mRTq1F5zR7kRWTomMUFT+obdgvnhHGC A2SiMDQAErSRLbj+k2yd++TOs7Ce7GSTWK0I7WjpespYcrNWMf1GfKFYt2N+0Byod+sS vtpiL3VI/96CfjPJCjp07Bf6wlxPSssbP9L0gJ/A2WQcK/ScLxkYIUO0hDlr7BILRWxP 7ojCN/Mi/02p7lELdjUIywzscAtlZhAEG0dou6bDKfnZDyJTRN+Y739DY9Flbyz9jQKu 2oUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=5u6WccQv02wGQwmPOCGRW8ANlKCyhwzyl3N76RvRkYA=; b=c7WB6MNty6GGe9hLEi/4l/hwCE7feM6AiaHQI9T3GEvYR7i/bOkUBbyBl9ueP6eUSV 6d0bxJ26WjuvJLgUONMj+cm6zxeK0c6SM0kvBim0Tml85j1hpda+F7Tv14+CwGfer+Cj POIhZFeRCgLMv1X1Dh7M8i5ifRL7+sKSt/z6p5e/A7RZw1HBR1Tep4vMDgPRzJn7R8Ww gzNIt02sz5/QQnTkqc+nErtAkF+cFQiSLu3/ZDcow5GjZWPnZa+YZFmbYYlW8mFujV2U 0YqaAHHGe6pAg3qzKU50kzo9gnZQKnYhccS61IfMD3x8jevKsIzwMyj2ENJuiw1y8Vk8 XX8A== X-Gm-Message-State: ACgBeo3+EDyuyanPuEXraDaXmABj27SFvMPS6iXvkpRyycewSluypAB5 OBaprgVgwwjNrG+TpuudA9PbSt7Bs1ooUiEgZUPPIA== X-Google-Smtp-Source: AA6agR5cc5ukGpCztzm/So1b31sXKsxK11rETbZa7gIoYgRgBB6LrEZDIDFNDuesbKjRkegSo095rnr/I/MurSWNswE= X-Received: by 2002:ac5:cb0a:0:b0:3a2:2fa3:87d8 with SMTP id r10-20020ac5cb0a000000b003a22fa387d8mr6110851vkl.3.1663182210236; Wed, 14 Sep 2022 12:03:30 -0700 (PDT) MIME-Version: 1.0 References: <20220913151853.153311-1-alx.manpages@gmail.com> <43da981a-5727-d521-9aa2-a56aa9cd2f53@gmail.com> In-Reply-To: From: JeanHeyd Meneide Date: Wed, 14 Sep 2022 15:03:19 -0400 Message-ID: Subject: Re: [PATCH] inttypes.h: imaxabs(3): Implement as a macro To: Joseph Myers Cc: Alejandro Colomar , Florian Weimer , libc-alpha@sourceware.org, JeanHeyd Meneide Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Dear Alejandro, Joseph, On Wed, Sep 14, 2022 at 12:41 PM Joseph Myers wrote: > > On Wed, 14 Sep 2022, Alejandro Colomar via Libc-alpha wrote: > > > > 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. > > > > Yes, and yet the same can be said about long long. intmax_t is one less > > character (both in the type name, and in "j"), but apart from that, no much > > benefit. > > It provides a clearer statement of intent to readers of the code than long > long does. > > As I noted in the WG14 discussions of a few proposed obsoletions, just > because some language feature is not useful for *all* the things some > people might like to be able to use it for isn't a reason for obsoletion > when it's still useful for *some* of those things. I agree here. I have a proposal to fix this, based on the assembly labels and similar existing practice found on a lot of compilers, and based on what BSDs such as NetBSD have been using for 25+ years to provide ABI stability despite shifting architectures and types: https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Transparent%20Aliases.html I would rather we not fall back to macros for all the reasons Joseph and others mentioned (the standard library #undef macro reason is also listed in the above-linked paper). I personally view the exemptions we made for the upcoming C2x (C23) standard as stop-gaps to allow important evolution and implementation work from, but not general-purpose solutions. I think transparent aliases is a generic solution to the problem and would achieve much of what we need to do, but it will not be in until C2y/C3a (the next revision of the C standard) if I work hard at it and polish the wording while surfacing implementations. I also found a few embedded folks who similarly suffered drawbacks because their platform's compiler could not deal with the asm("") labels for ABIs, and broke the entire build on their machine. So even for non-large systems, there's a real need for a language-level indirection mechanism that has all the same properties as normal functions. I hope that we can still make do with implementation extensions while I (and others?) work to make proper strides in implementation. And I apologize it took me this long to come up with these things; I certainly do wish I was "faster on the draw" to solving these problems, so to speak. Best Wishes, JeanHeyd