Problems with default _POSIX_C_SOURCE in features.h ??

[Adhemerval Zanella]

On 09/04/2019 14:12, Chris Hall wrote:
> On 09/04/2019 14:09, Adhemerval Zanella wrote:
>> On 01/04/2019 07:11, Chris Hall wrote:
>>> On 29/03/2019 17:54, Adhemerval Zanella wrote:
> ...
>>>> My understanding is _POSIX_C_SOURCE and _XOPEN_SOURCE are tests are
>>>> orthogonal and it will enable the most recent features you enable.
>>>> The  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 will set to higher
>>>> standard you set, which is _POSIX_C_SOURCE=200809L from _DEFAULT_SOURCE.
> ...
>> Now, I am not sure which would be best course of action on glibc for such
>> unspecified combinations. Current practice is to follow your description to
>> conditionality older XSI extension if where the case.
> 
> I think we are agreed that _POSIX_C_SOURCE and _XOPEN_SOURCE are not orthogonal.
> 
> ...
>> So my understanding is glibc is not promoting the -D_DEFAULT_SOURCE
>> -D_XOPEN_SOURCE=600 to _XOPEN_SOURCE=700 and it is indeed behaving as the manual states which is only setting -D_POSIX_C_SOURCE=200809L.
> 
> I think we are agreed that -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 select an undefined combination of _POSIX_C_SOURCE and _XOPEN_SOURCE.
> 
> Setting "the 2008 edition of POSIX" is indeed what the manual says.
> 
> So asking for -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 is to ask for something which is undefined.
> 
> However, glibc goes to some effort to support the selection of older _POSIX_C_SOURCE and/or _XOPEN_SOURCE.  But *not* with __USE_MISC and *not* with __USE_GNU.  I have failed to discover why that is -- though that is probably because I am too stupid.

My understanding is because both __USE_MISC and __USE_GNU are internal flags 
not meant to be set by external programs and they can be removed/added in
future glibc releases.

> 
> ...
>>> Except that _DEFAULT_SOURCE is (apparently) the only way of turning on __USE_MISC.
> 
>> The _GNU_SOURCE, which also defines _DEFAULT_SOURCE, also defines __USE_MISC.
> 
> True.  But I don't want GNU extensions -- so I was ignoring that.  I apologise for not being precise.
> 
> ...
>>> Perhaps:
>>>
>>> Â Â  1. _DEFAULT_SOURCE is intended to exclude XSI altogether.
> ...
>> That's not the idea, _DEFAULT_SOURCE does not *include* the XSI extension but also does not *exclude* them.  It is still
>> possible to include the XSI extension if is is the intention.
> 
> OK, so ...
> 
>>> Â Â  2. _DEFAULT_SOURCE is intended to not include XSI, but
>>> Â Â Â Â Â  _XOPEN_SOURCE may be used to add same.
>>>
>>> Â Â Â Â Â  The documentation does not rule this out.
> 
> ... -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=700 is an expected/supported combination (currently).
> 
> Mind you, when _POSIX_C_SOURCE=202101 (say) arrives and _DEFAULT_SOURCE selects it, -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=700 will then be an undefined/unsupported combination :-(
> 
> So, to correctly select XSI with _DEFAULT_SOURCE, I have to work on my configure script, to check (a) what version of _POSIX_C_SOURCE will be selected by _DEFAULT_SOURCE, and (b) what -D_XOPEN_SOURCE=??? is required to (correctly) enable XSI.  Hurrah !

The _DEFAULT_SOURCE was added on glibc 2.19 (commit c688b4196014e016) and
explicit stated that it implies -D_BSD_SOURCE -D_SVID_SOURCE 
-D_POSIX_C_SOURCE=200809L.  Also, glibc 2.20 changed change _BSD_SOURCE and 
_SVID_SOURCE to define _DEFAULT_SOURCE and later on 2.28 take in 
consideration _ISOC11_SOURCE as well.

So _DEFAULT_SOURCE always define -D_POSIX_C_SOURCE=200809L without 
implicit _XOPEN_SOURCE from glibc 2.19 to 2.30.  Afaik there is no need to
add a POSIX 2017 check, and it would require some discussion upstream
if it where the case to see how _DEFAULT_SOURCE will play along.

> 
>>> Â Â Â Â Â  If _XOPEN_SOURCE is defined, I would force it to 700,
>>> Â Â Â Â Â  to also be consistent with _GNU_SOURCE and be unambiguous.
> 
>> Again, I do not think it would be safer or yield much gains to
>> force either _DEFAULT_SOURCE or _POSIX_C_SOURCE=200809L to set
>> _XOPEN_SOURCE to 700.  Since it is undefined by standard and has been defined by glibc, it will most likely crate incompatibilities if we change it and it is not easy to create a compatibility layer for such cases.
> 
> Sorry, I don't understand this.
> 
> My point is: if I ask for XSI, by -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=xxx, I think it would be helpful if _DEFAULT_SOURCE selected the latest and greatest _XOPEN_SOURCE, to go with the latest and greatest _POSIX_C_SOURCE which _DEFAULT_SOURCEÂ  is also selecting...
> 
> ...so that, when _POSIX_C_SOURCE=202101 (say) arrives, _DEFAULT_SOURCE would then set the corresponding _XOPEN_SOURCE=800.

But _DEFAULT_SOURCE *explicit* from its addition on glibc *does not*
set XSI neither it is intention from original commit message. What you 
are asking is a explicit breakage of the flag semantic and glibc tries 
to avoid such changes.

> 
> I agree that anybody currently asking for (say) -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 might be surprised by the new result.  Though I think we are agreed that what they currently get is undefined :-(
> 
> Chris

The main problem in my view is there is no guarantee from glibc for which
_POSIX_C_SOURCE _DEFAULT_SOURCE will define in the future for possible new
_POSIX_C_SOURCE values. I think it is worth a discussion and I will raise
this question on libc-alpha.