This is the mail archive of the
mailing list for the glibc project.
Re: Problems with default _POSIX_C_SOURCE in features.h ??
- From: Chris Hall <glibc at gmch dot uk>
- To: libc-help at sourceware dot org
- Cc: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Date: Mon, 1 Apr 2019 11:11:30 +0100
- Subject: Re: Problems with default _POSIX_C_SOURCE in features.h ??
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
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
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).
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
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)?