This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problems with default _POSIX_C_SOURCE in features.h ??

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_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
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).


  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 and we try
to break things even it is just extra compile warning)?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]