From patchwork Tue Sep 13 15:18:54 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alejandro Colomar X-Patchwork-Id: 57599 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D3CB43856242 for ; Tue, 13 Sep 2022 15:21:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D3CB43856242 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1663082460; bh=jQxVdg/4e7A9yn7GQe1cQSMQqiCXGbrsF9kQUASZ0AA=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=oWQ7GKNFqfBvtKhy0BNvaq8RXS+irFhbrNCZGdtrnEXxghj1Ln0YFyoiFvg9TadA1 wzFdL7NMKGjeRu5TQ50oXd0qJT48LI79FEnreVN0mDae+OJ5r9r6UQImuvjq1imwfn whJjHodiqqqVJeuIDR+RegMz1fO+jP1yMkgbm0G0= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 49BAC3858D1E for ; Tue, 13 Sep 2022 15:20:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 49BAC3858D1E Received: by mail-wr1-x42b.google.com with SMTP id c11so21317386wrp.11 for ; Tue, 13 Sep 2022 08:20:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date; bh=jQxVdg/4e7A9yn7GQe1cQSMQqiCXGbrsF9kQUASZ0AA=; b=VaAWNxOJqA3pnTQgaoElw2BtZufpClTQL3seU+UFzf/EvcvK4c9fGBcynAMr1kyiye 2Y4CPi4ifYngvbmCSVD4qmByYzG/4NX+ii7ve5kj67Lwl1fz8BVfWhl0GIjphruVnbId Mn/x6weUwz8GmVY0LhoeEzi+L/grHKqhwa76kch/bCS0wgbak2wszEXWrSfZ5tGA+vY6 ZE4rJydqhTCu+Kst8A5JDGZgXmxfDv+X0qyiWPPYZaFWRSkbniSwLo0Y7DxYmFJu+f1s ASfYoFWSwOuf7AIXbKRbbcOHVZ2Sm2D+fjeM8t22pPXZZmyDparhbjkPacOeeCiN2wx5 /CmA== X-Gm-Message-State: ACgBeo2CGhOjvvFbgr5H8N4x4Wn2bAFdrNPnwCx4B6Ixfuzs0jpzz04H 5ZyW+ye4WHI1wVylFLL0wln8e7QfPnQ= X-Google-Smtp-Source: AA6agR7gZn9KNnAzv8aKvwOzZlkaJYyo5n+WUqE4+w6KpalEKruEJETz4/yumsCuxZmizQTrfuRltQ== X-Received: by 2002:a5d:453a:0:b0:228:7873:1101 with SMTP id j26-20020a5d453a000000b0022878731101mr18266584wra.241.1663082436949; Tue, 13 Sep 2022 08:20:36 -0700 (PDT) Received: from asus5775.alejandro-colomar.es ([170.253.36.171]) by smtp.googlemail.com with ESMTPSA id az9-20020a05600c600900b003b4935f04aasm3877985wmb.10.2022.09.13.08.20.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Sep 2022 08:20:36 -0700 (PDT) To: libc-alpha@sourceware.org Subject: [PATCH] inttypes.h: imaxabs(3): Implement as a macro Date: Tue, 13 Sep 2022 17:18:54 +0200 Message-Id: <20220913151853.153311-1-alx.manpages@gmail.com> X-Mailer: git-send-email 2.37.2 MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2798; i=alx.manpages@gmail.com; h=from:subject; bh=1+I0XjE7w1YINgBiFrYHFbNkwGSVZ4eTHROstROEjjM=; b=owEBbQKS/ZANAwAKAZ6MGvu+/9syAcsmYgBjIJ9Unq7Mij9qqdY4DwJML/a8V9scuFRXgDIj+2Ui s6hlo9KJAjMEAAEKAB0WIQTqOofwpOugMORd8kCejBr7vv/bMgUCYyCfVAAKCRCejBr7vv/bMnaPD/ 9VL4+okU1/5ochI9rrhe24eGccqgOoxT629UvUxRQNhrruaS0a9/sIo3FRrOwMb/BAp2M0n/AYHj3Q TuJvIPl62EvFDgk0Ry9Jv7PQXfPfpZG11ik/Cd4QhAwS5jsV7H7mHcnNyhRuEqM5d+oVpkhtg6MmY2 kv773uTF/Eua7b8XumkybebZEddpbbMsGP4rj2639c+nN+FWYOwEKDT/syaIN1lkXeGAU1s+ZEwCL1 re2zbMxa3Ka00jNpovVe49CaaebFZkyZ/V/rxQMlzKG9dgfDF8ZIzTt8gur7lkoVvcVa8zIi3UVaVW GRhZhhr9nJwCxl4tGeN01z4IXL8whCPy1n22lb5O3WqpFoPNKDm/KaVdd+JCMYwU4QERtFPvCVPpAM E9FvlJG1W6T2WiffS4Nq+wCrkpYomhmqQgeaLSktTWRwhUvOk4LM7JlypXYRlBBeIU4+vaZ6Jr2WOU RyNaAOvPMJ6K+nZ2XTukQ1SpD9LIwfOn2nbx7EzJ7O1cpXQSZLToHjuO4Ok1ZCNDQWBl7GK2lgnR8x Ki5uwiT1p8xp9Ju9R4rmtS6l+lFQxiyatgXQA78MTtjjHQcFbygnzYOFc7yW9bF8auCoVPTKYlW/wQ RJt8YGuCtvxP+Labd95KGoo4F1nh+eUmFDab77TJm69S2TpyIYmfrkWNt88A== X-Developer-Key: i=alx.manpages@gmail.com; a=openpgp; fpr=A9348594CE31283A826FBDD8D57633D441E25BB5 X-Spam-Status: No, score=-11.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, 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 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: , X-Patchwork-Original-From: Alex Colomar via Libc-alpha From: Alejandro Colomar Reply-To: Alex Colomar Cc: Alex Colomar , Florian Weimer , JeanHeyd Meneide Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" Functions using the [u]intmax_t types have a problem: ABI. The [u]intmax_t types were designed so that users could blindly use them to work with whatever is the biggest size for a given architecture. But this is problematic to implement. These days, ABI stability is very important, and programs compiled a specific version of glibc should continue working with newer glibc releases. Of course, that means that future glibc versions can't change the types of functions, or the functions would be incompatible. So, we cannot really change the (linker) signature of functions; not even of those using [u]intmax_t. A solution to that problem is to use macros, and not real functions. That way, the program really links against whatever function works with the compile-time maximum width type, be it long or long long, and the program will be bonded to the ABI of long or long long, but will know nothing about intmax_t. We still need a linker symbol with the name imaxabs(), for old programs linked against old glibc versions, and also for compatibility with an interpretation of the ISO C standard that says that imaxabs(3) is a function. But the standard knows nothing about ABI or a linker, so a macro that evaluates to a differently-named function is not a straight violation, but rather stepping through the line without crossing it, AFAIK. This implementation with C11 _Generic() is one that I used for the new _Generic(3) manual page. It allows treating the macro as a function, and to take pointers to it. And it allows to more easily understand the definition of the macro, without needing to parse the ifdefs. It makes it easier to parse with tools like grepc(1): $ grepc -k __PRI64_PREFIX inttypes.h inttypes.h:44:# define __PRI64_PREFIX "l" inttypes.h:47:# define __PRI64_PREFIX "ll" $ grepc -k imaxabs inttypes.h inttypes.h:290:#define imaxabs _Generic(INTMAX_C(0), long: labs, long long: llabs) If glibc can't use C11 features in public headers, then usual ifdefs could be used. Cc: Florian Weimer Cc: JeanHeyd Meneide Signed-off-by: Alex Colomar --- Hi Florian, What do you think about using this implementation of imaxabs(3) in glibc? Is it valid according to ISO C and/or POSIX? It's been a long time since I last built and tested glibc from so I haven't tested this patch yet. I'll try more seriously when it has some chances of being accepted. Cheers, Alex stdlib/inttypes.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/stdlib/inttypes.h b/stdlib/inttypes.h index d550769f2a..eb20e416ac 100644 --- a/stdlib/inttypes.h +++ b/stdlib/inttypes.h @@ -287,7 +287,7 @@ typedef struct /* Compute absolute value of N. */ -extern intmax_t imaxabs (intmax_t __n) __THROW __attribute__ ((__const__)); +#define imaxabs _Generic(INTMAX_C(0), long: labs, long long: llabs) /* Return the `imaxdiv_t' representation of the value of NUMER over DENOM. */ extern imaxdiv_t imaxdiv (intmax_t __numer, intmax_t __denom)