From nobody Tue Aug 25 16:16:12 2026 X-Original-To: dev-commits-src-main@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 4hTtFV2k4qz6pcyN; Tue, 25 Aug 2026 16:16:30 +0000 (UTC) (envelope-from dtf@shxd.cx) Received: from shxd.cx (shxd.cx [207.231.82.159]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4hTtFV0Px0z3RGN; Tue, 25 Aug 2026 16:16:30 +0000 (UTC) (envelope-from dtf@shxd.cx) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shxd.cx; s=shxd2024; h=Sender:References:To:Cc:In-Reply-To:Date:Subject:Mime-Version: Content-Type:Message-Id:From:Reply-to:Content-Transfer-Encoding:Content-ID: Content-Description; bh=jkW89/VYYYCz7SmJv9Q9BD2gmqdDy99IsgJUd3tOvIY=; b=NUByy XtVD6xXCe/cFX8xwIZOntB844ox6+Rn/HSDbHZr+eHRBMLUxOYWdhV9KhxGqnME8c3Xc5WM2oyNdx L6QGdqokkXwbYq4UbmviDNBpW+Wli5U+DIazxFAN98g0xFmH8EKY8WcEW7PbY3eaNBPxNqYEZgoOJ TMPRwt9KsxWk=; Received: from lummox.shxd.cx ([10.0.0.254]:62736 helo=smtpclient.apple) by shxd.cx with esmtpsa (TLS1.2) tls TLS_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1 (FreeBSD)) (envelope-from ) id 1wytoY-000000009XS-3rqX; Tue, 25 Aug 2026 09:15:54 -0700 From: Devin Teske Message-Id: <730AFA99-F6E9-4D78-BE52-54E1DEE3ABF4@freebsd.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_64611ADB-471B-4184-BFB4-FB82B9ED4D24" List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) Subject: Re: git: 8d29d2429649 - main - libc: Restore prior C23 include guards Date: Tue, 25 Aug 2026 09:16:12 -0700 In-Reply-To: <86ik4y4gsv.fsf@ltc.des.dev> Cc: Faraz Vahedi , Warner Losh , src-committers , "" , "" , Devin Teske To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= References: <6a85843a.3287f.2aec5cf8@gitrepo.freebsd.org> <865x0z6526.fsf@ltc.des.dev> <86wltf4mz8.fsf@ltc.des.dev> <86ik4y4gsv.fsf@ltc.des.dev> X-Mailer: Apple Mail (2.3864.600.51.1.1) X-Rspamd-Queue-Id: 4hTtFV0Px0z3RGN X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:14051, ipnet:207.231.64.0/19, country:US] X-Spamd-Bar: ---- : at_start: {auth_results {shxd.cx}} --Apple-Mail=_64611ADB-471B-4184-BFB4-FB82B9ED4D24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 25, 2026, at 3:48=E2=80=AFAM, Dag-Erling Sm=C3=B8rgrav = wrote: >=20 > Faraz Vahedi writes: >> Since these macros solely advertise which revision of the header our >> libc implements and are neither a language-mode nor visibility = switch, >> I believe we=E2=80=99re fine. C23-only identifiers are already gated = on our >> visibility macros, and exposure of these feature test macros per se >> are not of any harm, even for libraries targeting modes prior to C23. >> For the same very reason, it is also fine to have these as include >> guards (which brand new C23 headers like and >> still do). >>=20 >> My restoration of traditional guards was just to avoid any possible >> POLA violation for those depending on them (albeit wrong) as reported >> by dim for math/gmp port as an example. >=20 > Just because you don't understand why they did it doesn't mean it's > wrong. It just means you're young and inexperienced and have no > business making categorical statements like the above. Please make = the > __STDC_VERSION macros conditional on __ISO_C_VISIBLE >=3D 2023 || > __BSD_VISIBLE. >=20 > DES > --=20 > Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org >=20 Dag-Erling, I looked at this because I wanted to understand the failure you described rather than let it sit as a yes/no on the restore. You wrote that a library might offer C23 extras predicated on __STDC_VERSION_*, and that a C99 program using that library would then fail to build because we define the macros unconditionally. That is a real problem if the macros are acting as a visibility predicate. The way I have been reading ISO/IEC 9899:2024, 7.1.2p6 [1] is that they advertise which revision of the header our libc implements, so a program can ask the library a question -std=3Dc23 cannot answer. Language mode is still __STDC_VERSION__ (6.10.10.2). Our C23 identifiers are already predicated on __ISO_C_VISIBLE [2] =E2=80=94 = BOOL_MAX and the rest =E2=80=94 so a -std=3Dc99 translation unit should not see = those identifiers either way. If someone uses __STDC_VERSION_*_H__ to inject C23 syntax of their own, they are asking the advertisement to do visibility's job. I may be missing a case where that is the right test; I have not found it in 7.1.2p6 yet. Your predicate (__ISO_C_VISIBLE >=3D 2023 || __BSD_VISIBLE) would make the macros mean "this compilation can see C23 semantics from this header." That is a policy we can talk about on its own. I would rather not fold it into the _FOO_H_ restore, which was only POLA after gmp. If I have the split wrong, I would like to hear it. Devin [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf [2] https://reviews.freebsd.org/D47576 --Apple-Mail=_64611ADB-471B-4184-BFB4-FB82B9ED4D24 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 25, 2026, at 3:48=E2=80=AFAM, Dag-Erling = Sm=C3=B8rgrav <des@FreeBSD.org> wrote:

Faraz Vahedi = <kfv@FreeBSD.org> writes:
Since these = macros solely advertise which revision of the header our
libc = implements and are neither a language-mode nor visibility switch,
I = believe we=E2=80=99re fine.  C23-only identifiers are already gated = on our
visibility macros, and exposure of these feature test macros = per se
are not of any harm, even for libraries targeting modes prior = to C23.
For the same very reason, it is also fine to have these as = include
guards (which brand new C23 headers like <stdbit.h> and = <stdckdint.h>
still do).

My restoration of traditional = guards was just to avoid any possible
POLA violation for those = depending on them (albeit wrong) as reported
by dim for math/gmp port = as an example.

Just because you don't understand why = they did it doesn't mean it's
wrong.  It just means you're young = and inexperienced and have no
business making categorical statements = like the above.  Please make the
__STDC_VERSION macros = conditional on __ISO_C_VISIBLE >=3D 2023 = ||
__BSD_VISIBLE.

DES
--
Dag-Erling Sm=C3=B8rgrav - = des@FreeBSD.org


Dag-Er= ling,

I looked at this because I wanted to = understand the failure you
described rather than let it sit as = a yes/no on the restore.

You wrote that a = library might offer C23 extras predicated on
__STDC_VERSION_*, = and that a C99 program using that library would
then fail to = build because we define the macros unconditionally. =  That
is a real problem if the macros are acting as a = visibility
predicate.

The way I have = been reading ISO/IEC 9899:2024, 7.1.2p6 [1] is that
they = advertise which revision of the header our libc implements, so = a
program can ask the library a question -std=3Dc23 cannot = answer.
Language mode is still __STDC_VERSION__ (6.10.10.2). =  Our C23
identifiers are already predicated on = __ISO_C_VISIBLE [2] =E2=80=94 BOOL_MAX
and the rest =E2=80=94 = so a -std=3Dc99 translation unit should not see = those
identifiers either way.

If = someone uses __STDC_VERSION_*_H__ to inject C23 syntax of = their
own, they are asking the advertisement to do = visibility's job.  I may
be missing a case where that is = the right test; I have not found it in
7.1.2p6 = yet.

Your predicate (__ISO_C_VISIBLE >=3D = 2023 || __BSD_VISIBLE) would make
the macros mean "this = compilation can see C23 semantics from this
header." =  That is a policy we can talk about on its own.  I = would
rather not fold it into the _FOO_H_ restore, which was = only POLA after
gmp.

If I have the = split wrong, I would like to hear = it.

Devin



= --Apple-Mail=_64611ADB-471B-4184-BFB4-FB82B9ED4D24--