From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.cs.ucla.edu (mail.cs.ucla.edu [131.179.128.66]) by sourceware.org (Postfix) with ESMTPS id 0F41C3858CDA for ; Wed, 14 Jun 2023 02:54:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0F41C3858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id A204E3C09FA2C; Tue, 13 Jun 2023 19:54:28 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id UTxRwUGqXMiq; Tue, 13 Jun 2023 19:54:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 5B7F73C09FB42; Tue, 13 Jun 2023 19:54:28 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 5B7F73C09FB42 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1686711268; bh=tX2/zLpL7+G+sicdS7HcM7s1dMloyyCC2qH/6UepYKw=; h=Message-ID:Date:MIME-Version:To:From; b=obkYizyBc17X/ti7My49+Mi5Uc/6ME7NgP0EgYDg2qlqd6L2LW+4ZxxXOP17WZ73F JCGA13MOhF28KfkeiKBvOZvh1javx3iIuHcWcL7OYC9hdPziSP6PdPyARcaEVprpYE 7hIViqSPHHc4fPqb9JGhZAgqP3H37oNjmoSEx4kzZh/dgzUUeuF4GK16XcS0ox35pC qy4FVKv8slMrHZweMp/OF1qKGn6ByNR6RR489zt6cpW5vgCYjLSSkxTAiSN9vvuCQG 8nxS71u/il9lRl2j/3GjexJ873g36mfQaqWkuF/jWOHIRTmuvUmNQFNShSf5mtAw8u vlkQ+mwOAilvw== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uPhE6k-DHW6O; Tue, 13 Jun 2023 19:54:28 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 3F6823C09FA2C; Tue, 13 Jun 2023 19:54:28 -0700 (PDT) Message-ID: Date: Tue, 13 Jun 2023 19:54:25 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [RFC] Add stdckdint.h header for C23 Content-Language: en-US To: Jakub Jelinek , Joseph Myers Cc: Marek Polacek , gcc-patches@gcc.gnu.org, libc-alpha@sourceware.org References: <68578b43-939-1879-9676-2ea55249a2c5@codesourcery.com> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KAM_NUMSUBJECT,NICE_REPLY_A,SPF_HELO_NONE,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 6/12/23 23:28, Jakub Jelinek via Libc-alpha wrote: > On Mon, Jun 12, 2023 at 09:51:02PM +0000, Joseph Myers wrote: >> On Sat, 10 Jun 2023, Jakub Jelinek via Gcc-patches wrote: >> >>> I have looked at gnulib stdckdint.h and they are full of workarounds >>> for various compilers, EDG doesn't do this, clang <= 14 can't multiply >>> __int128, ..., so I think the header belongs into the compiler rather >>> than C library, because it would be a nightmare to maintain it there. I tend to agree. I don't see how to implement in the C library, at least not for the C library's users. It would be possible to implement for C library internal use only, because then we could assume #include_next, and we could use the Gnulib implementation safely (that implementation is already present glibc internals, just under a different name). This could well be worth doing, because glibc internally needs ckd_add (or something equivalent) but glibc can't yet assume that it's built with GCC 14 (or whatever GCC version eventually supports ). > There is always the possibility to have the header co-owned by both > the compiler and C library, limits.h style. > Just > #if __has_include_next() > # include_next > #endif I don't see how you could implement __has_include_next() for arbitrary non-GCC compilers, which is what we'd need for glibc users. For glibc internals we can use "#include_next" more readily, since we assume a new-enough GCC. I.e. we could do something like this: #if 14 <= __GNUC__ # include_next #else # define ckd_add(r, a, b) INT_ADD_WRAPV (a, b, &(r)) #endif where INT_ADD_WRAPV is the already-existing glibc internal macro, and where we invoke ckd_add only with arguments free of side effects.