This is the mail archive of the libc-help@sourceware.org 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 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.
> 
> 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...) !!

Indeed POSIX states that XSI (defined by _XOPEN_SOURCE) is a superset of the
mandatory requirements for conformance to POSIX.1 (defined by _POSIX_C_SOURCE).

Now, from my understanding of POSIX.1-2001 [1] conformance it does *not* really
define the combination you use as example, -D_XOPEN_SOURCE=600 with 
_POSIX_C_SOURCE=200809L. It does not fall neither on 'Strictly Conforming POSIX 
Application' (which shall define _POSIX_C_SOURCE to be 200112L) nor on 'Strictly
Conforming XSI Application' category ('which shall define  _XOPEN_SOURCE to be 600).

Also, based on POSIX.1-2017 I would say this behaviour is now currently stated
as unspecified, since it states that:

"However, should _POSIX_C_SOURCE be set to a value greater than 200809L, the 
behavior is unspecified."

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.

[1] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap02.html
[2] http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html

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

I think the issue is -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 from glibc
documentation states _DEFAULT_SOURCE will implicit sets _POSIX_C_SOURCE=200809L 
is also undefined (since for _POSIX_C_SOURCE=200809L it expects 
-D_XOPEN_SOURCE=700 to be a Strictly Conforming XSI Application).

Now what glibc does is:

$ gcc -Wall test.c -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=600 -E -dD | grep __USE_XOPEN | grep define
#define __USE_XOPEN2K 1
#define __USE_XOPEN2K8 1
#define __USE_XOPEN 1
#define __USE_XOPEN_EXTENDED 1
#define __USE_XOPEN2K 1
#define __USE_XOPEN2KXSI 1

$ gcc -Wall test.c -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -E -dD | grep __USE_XOPEN | grep define
#define __USE_XOPEN2K 1
#define __USE_XOPEN2K8 1
#define __USE_XOPEN 1
#define __USE_XOPEN_EXTENDED 1
#define __USE_XOPEN2K8 1
#define __USE_XOPEN2K8XSI 1
#define __USE_XOPEN2K 1
#define __USE_XOPEN2KXSI 1

$ gcc -Wall test.c -D_DEFAULT_SOURCE  -E -dD | grep __USE_XOPEN | grep define
#define __USE_XOPEN2K 1
#define __USE_XOPEN2K8 1

$ gcc -Wall test.c -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -E -dD | grep __USE_XOPEN | grep define
#define __USE_XOPEN2K 1
#define __USE_XOPEN2K8 1
#define __USE_XOPEN 1
#define __USE_XOPEN_EXTENDED 1
#define __USE_XOPEN2K 1
#define __USE_XOPEN2KXSI 1

$ gcc -Wall test.c -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=700 -E -dD | grep __USE_XOPEN | grep define
#define __USE_XOPEN2K 1
#define __USE_XOPEN2K8 1
#define __USE_XOPEN 1
#define __USE_XOPEN_EXTENDED 1
#define __USE_XOPEN2K8 1
#define __USE_XOPEN2K8XSI 1
#define __USE_XOPEN2K 1
#define __USE_XOPEN2KXSI 1

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.


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

The _GNU_SOURCE, which also defines _DEFAULT_SOURCE, also defines __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.

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.

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

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.

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

No, __USE_MISC is used to add *GNU* extension and tying it to _XOPEN_SOURCE
is definitely wrong. It is safe for _DEFAULT_SOURCE because it is also a
glibc extension.

> 
> 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)?
> 
> 
> 


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