From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by sourceware.org (Postfix) with ESMTPS id 1510A3858C5E for ; Wed, 14 Jun 2023 15:51:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1510A3858C5E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F2EBD5C003D; Wed, 14 Jun 2023 11:51:00 -0400 (EDT) Received: from imap45 ([10.202.2.95]) by compute1.internal (MEProxy); Wed, 14 Jun 2023 11:51:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1686757860; x=1686844260; bh=AQ KjLxwltPcn/7w0Ff0C0OkbSTF6583S60cyGRAorh0=; b=SRhmfIIZK1NuRLP8wL 1zGw+3zrmcDlVU6hEIpKepDJxMbVrYl6Feog001RB+c7ujNynJJas0pkUr8cZLPF ynfGnB7UAFLh+T8LcBJJ6zw6C3gcJ6kpjmxCFeqqa+IK3u7VTCDhdxkaU9GaknlQ Z6RMMPGLU0xrIxnsKoqaspDq8hIkHHO3yKmyw+kC7kJHgSrEPZVS0NPAdOmPfFWZ QLW/YSA1IexhJU1/HCioRg54G+oNK/AC2MK1ViiYpwftR350n0rU+3mkADd+NyNB Znn3MJozxDrtQawHOsqNu7uowYrDi8rEBr8X/oLXsunSWpWW0WBnd97hzoJylf3M x8EA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1686757860; x=1686844260; bh=AQKjLxwltPcn/ 7w0Ff0C0OkbSTF6583S60cyGRAorh0=; b=TeAScncKS7+MVTr4ssq+EoyFbaS0w FDJwof4Cel0GJi2l5FY/wC2paIfDX1ZSR9YWmC823UsXJFPW8GGMi08+xod/MnKy JKrfq+U+cua7O6l5uW5LwCvk6VgD8IBGK7Ov8WBrjKaVPVwG0T45J0DZE0bjnbms SdujIba0io3uYDAkLJ26z/0gMQH0EGH7UljtD9pvgj2oMxnVqQorzyL1LsCnNE84 SYe7aI2RGnMC9rsJuZ4KHHZcSrXc9d0A+BIWsrY53StUNdket9milzJGsDT08vu8 oxS7A06RQgBjO8s7fvIaCxNGVFYiwoouzitDIIRxUgpkjWV7SOvxwopmg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedvtddgleehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedfkggr tghkucghvghinhgsvghrghdfuceoiigrtghksehofihlfhholhhiohdrohhrgheqnecugg ftrfgrthhtvghrnhephfelfeehudfhleegheegjeevheeuieehvdfgueeuteetleeiieet heefhfeludeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepiigrtghksehofihlfhholhhiohdrohhrgh X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 89970272007A; Wed, 14 Jun 2023 11:51:00 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-492-g08e3be04ba-fm-20230607.003-g08e3be04 Mime-Version: 1.0 Message-Id: <712c5a01-b6a2-403a-b0be-172b295454f3@app.fastmail.com> In-Reply-To: References: <68578b43-939-1879-9676-2ea55249a2c5@codesourcery.com> Date: Wed, 14 Jun 2023 11:50:40 -0400 From: "Zack Weinberg" To: "Joseph Myers" , "Paul Eggert" Cc: "Jakub Jelinek" , "Marek Polacek" , gcc-patches@gcc.gnu.org, "GNU libc development" Subject: Re: [RFC] Add stdckdint.h header for C23 Content-Type: text/plain X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,KAM_NUMSUBJECT,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,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: On Wed, Jun 14, 2023, at 10:52 AM, Joseph Myers wrote: > On Tue, 13 Jun 2023, Paul Eggert wrote: > >> > 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: > > Given the possibility of library functions being included in > in future standard versions, it seems important to look > at ways of splitting responsibility for the header between the > compiler and library, whether with __has_include_next, or compiler > version conditionals, or some other such variation. limits.h is a horrible mess, with both the compiler and the library trying to get the last word, and I don't think we should take it as a model. I suggest a better model is GCC 12's stdint.h, where the compiler provides "stdint-gcc.h" that's used *only* in freestanding mode, and a wrapper header that defers to the C library (using #include_next, which is safe in GCC-provided headers) when __STDC_HOSTED__ is defined; meanwhile, glibc's stdint.h doesn't look for compiler-provided headers at all. In this case it sounds like glibc needs the compiler to provide some of the definitions, and I suggest this should be done via private predefined macros, in the mode of __INTx_TYPE__ and friends. zw