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

Mark Millard <[email protected]>
Newsgroups gmane.os.freebsd.devel.cvs.src
Message-ID <1b320a93-e6b9-4645-a6b2-37788cb84913__38470.0169715629$1786828952$gmane$org@yahoo.com>
On 8/15/26 11:37, Faraz Vahedi wrote:
> Hello Dimitry,
> 
> Thanks for the report.
> 
>>> The test used by this package seems defective.
>>> I don't think we should try to support such defective code.
>>> Perhaps the gmp source can be patched to check for
>>> __STDC_VERSION_STDIO_H__?
>>
>> Of course it could, and the patch is pretty simple. But I do not agree
>> that the code is "defective". Before C23, there was no standard way of
>> checking whether you had FILE declared.
> 
> The approach is neither portable nor standard, and therefore I believe we
> should not contaminate our libc with an unnecessary compatibility macro.
> If gmp requires FILE, including <stdio.h> would be sufficient, and if for any
> reason it prefers not to include it and instead relies on some indication,
> that issue should be addressed therein.  We can patch the port and, in
> parallel, submit a fix upstream.
> 
> I honestly expected that we might encounter a case like this, but I would
> appreciate it if we could avoid defining an unnecessary macro solely to
> accommodate an approach that is not standards-compliant.
> 
>> That said, I have applied such a patch locally, and it seems to work.
>> But obviously a maintainer of a port would say "this has worked for 20
>> years, why change it now" ? :)
> 
> I agree that it is a reasonable argument for a port maintainer, but it doesn’t
> really establish that the approach is correct or portable.  It only establishes
> that the particular set of libc implementations the port has encountered
> happened to expose the macro it was looking for.
> 
> If the port is relying on an implementation-defined include guard, then a libc
> changing that guard is not, strictly speaking, breaking a supported interface.
> Consequently, the appropriate fix is for the port to fix it rather than for libc to
> preserve it indefinitely as a compatibility interface that is neither established
> nor widely recognised.
> 
> Cheers,
> Faraz

I might put it another way: if there is now a standard compliant way to
do the detection for some range of C standards (even a singleton), gmp
upstream should likely be updated to allow that way to work for it for
that range. That would involve continuing the historical-examples based
tests technique otherwise.

It might be that __STDC_VERSION_STDIO_H__ should be tested by gmp for
even when compiled for a C predating C23. (Not likely to have
inappropriate matching activity.) But FreeBSD might not be the only
context for the older _STDIO_H_ reference in gmp, so gmp likely would
not remove that usage.

I view all that as separate from if the include/stdio.h (or the like)
for FreeBSD should have _STDIO_H_ removed from being in the
historically-accessible programming interface. I do not know if the
principle of least astonishment should win here.

-- 
===
Mark Millard
marklmi at yahoo.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.