Re: git: cd0727ec709b - main - libc: Add <stdio.h> C23 feature test macro

On 8/17/26 13:28, Warner Losh wrote:
> On Mon, Aug 17, 2026 at 11:16 AM Faraz Vahedi <kfv@freebsd.org> 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