From nobody Tue Aug 18 13:27:41 2026 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4hPVqy0FHWz6pBdV; Tue, 18 Aug 2026 13:27:42 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hPVqx6pjTz3Rg7; Tue, 18 Aug 2026 13:27:41 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1787059662; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2wHLaykKu+aHqTN7Sqp+J5sz26f8/2B8YPUUtYFsJ88=; b=Ja+9VKeAE6yU36S7By1CUDxQuxj6R1ucu62ofqG/ZP79wnWEXJ5a+qI4huIw41kLXPjRdk /RBrvCodDbU2wMaLzRHlQ8i5yb7i8g0pKhtQboXLmuL39Pw978QwWrq5xw0V3pWh0T5Oqx pl8LqTNW2S9UA48Yt3nvszNuGcYvfbyx8PduSiGLcyMQ0tZnwawwwx74sXawxmlY3b74Sh GV2bnyeD/x5F/1U0wRwrYlTYx9j3rC9yGtyuZRIPdM0w/xa1nQseZiNyRUBl8juTAyUSoZ eV516HI12xIUK9WtpggnLE8hu2tXQIfS+d0+FVrpQJAPkjtEr4FThY5cOCjBYw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1787059662; a=rsa-sha256; cv=none; b=hSnCm268q6xOfGmL89r47hkzhNFrTMhWzUoDmJJf1MNQyIa/Xd4k+bHdQaZk/OVdT4YpEX eT/SNVJUTAUHAR5czM0DiqEYdXbUc65m0gRVjxDL2u5KZkavWMikICuzpOg0wUP9QFikhl EKQrv0yJ5qjvhjOppDJoCYjKnfZtNDs/oPeU6Tj8fQ/TFrcyyRrwTbcsHcEVAmddlomqgZ FtvTCYUHZ4g+kKVGZLrPzIEyKZed2Xe34Cxnfoe8C4sWx/oyN5NaKE3DxU+Sm72n2kaMcp UaL/bry4aLxbtkIQaYZeiZP80KBDt5Ji8ZRPSBz+En7RORginLBvo984kV8+cQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1787059662; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2wHLaykKu+aHqTN7Sqp+J5sz26f8/2B8YPUUtYFsJ88=; b=uzwHJz62HSyB7bmfjealy11OzkgdtQIfSSDGaSlWqAcbdFBS/InVvQumYlFcaA0wnL4qTx W2kSys8Ed7GQcHuy/UoIXJHqyTVM9HpZFgYE/spgitZxt+vG6KVPNs3f6JQhm/xsGZfCma cvV1ZDbUq3hGHhhrSkcCeOCZm6CeujGqr99ABVJgxR5rdVi3+0G26BBbixWAS7zsCBDQUU TQQ2Ey0WmHN2A/Lvx+H+zE2AdTb2U4NksTWJ/8ga+mQlrPsUfcVhsLKlscULRvPJYQLud0 ZK5Qc+WKvCW21gHGoHZc14DtvT56j1mP86gHDApLCJX7QHQomqQNSO4mP6lI/w== Received: from [IPV6:2601:5c0:4202:5670:c96d:e4c2:feef:9a90] (unknown [IPv6:2601:5c0:4202:5670:c96d:e4c2:feef:9a90]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4hPVqx48gJz1MsT; Tue, 18 Aug 2026 13:27:41 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Tue, 18 Aug 2026 09:27:41 -0400 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: cd0727ec709b - main - libc: Add C23 feature test macro Content-Language: en-US To: Warner Losh , Faraz Vahedi Cc: Dimitry Andric , Robert Clausecker , "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" References: <6a7f6d6a.372ae.3079abac@gitrepo.freebsd.org> <3521D35A-40D0-48B6-808C-E18C15FC69D8@FreeBSD.org> <27042403-75C3-42B2-B41D-743FAC40885F@FreeBSD.org> <0BDC718D-ED95-4024-AD57-347591771031@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/17/26 13:28, Warner Losh wrote: > On Mon, Aug 17, 2026 at 11:16 AM Faraz Vahedi wrote: > >> Hello John, >> >>> This is not a realistic stance. There is a lot of software in the world >>> written before C23 was standardized, and we cannot expect that ports will >>> only contain C23 software. dim@'s patch looks sane to me and seems >> like the >>> reasonable path foward. It also matches our historic behavior which has >> been >>> to add new macros when required, but not retire existing header include >> guards >>> when doing so. >> >> I understand, you're right, but relying on something that's only >> internally established >> isn't a compatibility promise we need to uphold (please note that all >> identifiers that >> begin with either an underscore or a double underscore followed by an >> uppercase >> letter are considered reserved per §6.4.2.1). It doesn't break any >> compatibility, and >> in this case, and similar ones if they come up, we've only changed what we >> had >> internally decided to use so far, and hence I don't think it's a POLA >> violation. >> >> I understand the importance of taking care of ports, but I fear it may, in >> such cases, >> cause us to adopt unnecessary complications. That said, I'd like us to >> wait a little >> longer and discuss this further. If we all agree on restoring the macro, >> then we will >> do so. >> > > We've had these identifiers for the last 30 years or more. Removing them > actually > is a POLA violation because our headers have been inadequate in a number of > different ways over the years, so people use these internal details for > various purposes. > > So pedantically, you're correct: Who cares, we can change these > implementation > details at any time and we'll only break unportable code. However, > practically, this > formation (or similar) is rather wide-spread and we can't just say 'don't > do it' w/o > having an unacceptably large blast radius. > > So we need to keep them for a while, at least. And it's probably not just "a few" ports. This kind of assumption ends up baked into very-widely used portability libraries like gnulib and autoconf bits that impact lots of software. In this case it is only math/gmp that we know about so far, but dim@ is right in his original request that you need to do an exp-run for these types of changes before committing to understand the impact. I think for "science" you need to do an exp-run one way or another. Probably you should either revert the commit or apply Dimitry's patch so that main/ is stable (math/gmp is a dependency of binutils and gcc so it being broken is probably breaking lots of ports) and then request an exp-run for a patch that removes the guard so you can evaluate what the fallout is and how many ports would need to be fixed. It is probably worth sending a patch upstream to the gmp folks to use the C23 macro if it exists regardless. -- John Baldwin