Re: git: 28cecfe27964 - main - libc: Restrict ATOMIC_VAR_INIT for C23 conformance

On 6/22/26 05:13, Faraz Vahedi wrote:
> Hey Robert,
> 
>>> First, let me add that in case we decide to keep the __BSD_VISIBLE gate, the
>>> condition needs to be reconsidered entirely, since __BSD_VISIBLE is 1 in the
>>> default environment and makes the __ISO_C_VISIBLE check unreachable in the
>>> common case. Ergo, with no explicit feature-test macros, __BSD_VISIBLE is 1
>>> unconditionally and the condition __BSD_VISIBLE || __ISO_C_VISIBLE < 2023
>>> erroneously exposes ATOMIC_VAR_INIT even when compiled with -std=c23,
>>> which the C23 standard explicitly removed.
>>
>> That would be correct then.
>> We provide this macro as an extension, even if the standard no longer supplies
>> it, unless the configuration is set up to disable extensions.
>> This is the same policy we follow with all libc symbols and macros, unless
>> there is a solid reason not to provide them at all (e.g. due to a type change
>> or conflict with a more recent feature).
> 
> Oh, alright, now I get the point. I'll keep it in mind. Thanks to both of you for taking
> the time to explain. It took me a while to get there, but it's well established in my
> head now.
> 
> Cheers,
> Faraz

Some alternate (incomplete) wording that also fits --but is more
language standard point of view biased for what little it covers:

Generally, and generally deliberately, language/library standards tend
to say a lot about what must be present and how something that is
explicitly optional should be present if it is. They tend to avoid
declaring much about what cannot be present, including about most things
previously present in prior variants of the standard that are no longer
present. Such things are generally not significantly constrained by such
a standard.

-- 
===
Mark Millard
marklmi at yahoo.com