Problems with default _POSIX_C_SOURCE in features.h ??

[Chris Hall]

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.

My reading of the standards SUSv1 through SUSv4 is that _POSIX_C_SOURCE 
selects a subset of the corresponding _XOPEN_SOURCE.  So, if I ask for 
-D_XOPEN_SOURCE=600, I am asking for _POSIX_C_SOURCE=200112L with all 
the XSI additions and subtractions of SUSv3.  If I were to ask for 
-D_XOPEN_SOURCE=600 with _POSIX_C_SOURCE=200809L, I would be asking for 
the non-XSI subset of SUSv4 with all the XSI additions and subtractions 
of SUSv3.  The standard does not define the 12 mismatched combinations 
of non-XSI and XSI parts of SUSv1 through to SUSv4 (and 27 such 
combinations when SUSv5 arrives...) !!

Now, the standard says _XOPEN_SOURCE takes precedence.  Let "psx(X)" be 
the _POSIX_C_SOURCE corresponding to _XOPEN_SOURCE=X.  If I ask for 
-D_XOPEN_SOURCE=X with -D_POSIX_C_SOURCE=P then P is (effectively) 
ignored iff P <= psx(X).  That would leave (just) 6 possible 
combinations where P > psx(X) (and 10 with SUSv5).  The standard does 
not attempt to tackle the complexity -- those combinations are *undefined*.

Of course, glibc may support the undefined combinations.  The manual 
does not mention it -- though that is not a strong statement :-(

Perhaps glibc takes -D_XOPEN_SOURCE=X with -D_POSIX_C_SOURCE=P, and 
promotes the older to match the newer ?

But, as you say, for -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600:

> It will define as expected:
> 
> #define __USE_POSIX 1
> #define __USE_POSIX2 1
> #define __USE_POSIX199309 1
> #define __USE_POSIX199506 1
> #define __USE_XOPEN2K 1
> #define __USE_XOPEN2K8 1
> #define __USE_XOPEN_EXTENDED 1
> #define __USE_UNIX98 1
> #define __USE_XOPEN2KXSI 1

where __USE_XOPEN2K8XSI is not defined -- so if glibc is promoting the 
_XOPEN_SOURCE to 700, it's not obvious.

>> Perhaps it is not useful to ask for _DEFAULT_SOURCE and _XOPEN_SOURCE ?
> That my point: it does not make sense to set _DEFAULT_SOURCE, which will
> set _POSIX_C_SOURCE=200809L, and at same time set _XOPEN_SOURCE=600, which
> will set _POSIX_C_SOURCE=200112L.

Except that _DEFAULT_SOURCE is (apparently) the only way of turning on 
__USE_MISC.

....
>> Perhaps _DEFAULT_SOURCE should act like _GNU_SOURCE and override both
>> _POSIX_C_SOURCE *and* _XOPEN_SOURCE ?  If _XOPEN_SOURCE is defined it
>> could either be #undef'd or forced to 700.

> No sure what exactly do we gain for such change, and although I think a
> possible build breakage to be unlikely it is still a gratuitous change
> of semantic for _DEFAULT_SOURCE.

We agree that, given what _DEFAULT_SOURCE does, it makes no sense to 
also ask for _XOPEN_SOURCE=X, unless X matches the current latest and 
greatest _POSIX_C_SOURCE (known to glibc).

Perhaps:

   1. _DEFAULT_SOURCE is intended to exclude XSI altogether.

      The documentation suggests that is the case.

      So specifying *any* _XOPEN_SOURCE makes no sense.

      I would #undef _XOPEN_SOURCE to be consistent with _GNU_SOURCE,
      and be unambiguous.

   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.

      If _XOPEN_SOURCE is defined, I would force it to 700,
      to also be consistent with _GNU_SOURCE and be unambiguous.

   3. _XOPEN_SOURCE implies __USE_MISC

      In which case there is no need to use _DEFAULT_SOURCE and
      _XOPEN_SOURCE together.

      Given the "default" nature of _DEFAULT_SOURCE, I would #undef
      it if _XOPEN_SOURCE were specified.

      BUT: I note that _GNU_SOURCE => _DEFAULT_SOURCE => __USE_MISC.

           I have no idea whether that is significant.  But it does
           suggest that _XOPEN_SOURCE does *not* imply __USE_MISC.

But, yes, there could be somebody out there using (say) 
-D_XOPEN_SOURCE=600 -D_DEFAULT_SOURCE even though it makes no sense.

> Do we really need it (this lwn has
> some history of the change https://lwn.net/Articles/590381/ and we try
> to break things even it is just extra compile warning)?