Problems with default _POSIX_C_SOURCE in features.h ??

[Adhemerval Zanella]

On 29/03/2019 12:13, Chris Hall wrote:
> On 28/03/2019 18:56, Adhemerval Zanella wrote:
>> On 26/03/2019 17:28, Chris Hall wrote:
>>>
>>> features.h (in glibc 2.29, 31-Jan-2019) includes:
>>> ______________________________________________________________________
>>> /* If none of the ANSI/POSIX macros are defined, or if _DEFAULT_SOURCE
>>> Â Â Â  is defined, use POSIX.1-2008 (or another version depending on
>>>     _XOPEN_SOURCE).  */
> ...
>>> But this does not do what the comment says it does :-(
>>>
>>> If _DEFAULT_SOURCE is defined, but neither POSIX_SOURCE nor
>>> _POSIX_C_SOURCE are defined, this sets _POSIX_C_SOURCEÂ Â Â  200809L,
>>> no matter what _XOPEN_SOURCE is.
>>>
>>> Bug #1 ??
> 
>> I think the issue is the comment itself, since on glibc doc it states:
>>
>> manual/creature.texi
>>
>> 219 @defvr Macro _DEFAULT_SOURCE
>> 220 @standards{GNU, (none)}
>> 221 If you define this macro, most features are included apart from
>> 222 X/Open, LFS and GNU extensions: the effect is to enable features from
>> 223 the 2008 edition of POSIX, as well as certain BSD and SVID features
>> 224 without a separate feature test macro to control them.
>>
>> So my understanding is the intentio of _DEFAULT_SOURCE is indeed to
>> support current POSIX 2008 (or the latest release) regardless of the
>> _XOPEN_SOURCE value.
> 
> Well, the manual doesn't actually say how _DEFAULT_SOURCE interacts with _XOPEN_SOURCE and _POSIX_C_SOURCE if one or both are defined.
> 
> I observe that _GNU_SOURCE discards any _XOPEN_SOURCE and/or _POSIX_C_SOURCE settings -- it forces 700 and 200809L, respectively. Though the manual does not specify that, either.

The manual implicit does state that:

"If you define this macro, everything is included: ISO C89, ISO C99, 
*POSIX.1*, POSIX.2, BSD, SVID, X/Open, LFS, and GNU extensions."

I give you that it might be clear that _XOPEN_SOURCE and/or 
_POSIX_C_SOURCE would be ignore to pre-defined values.

> 
> [So it is not possible to compile as if for an older _GNU_SOURCE (with, say, 600 and 200112L).  Perhaps that's really not useful ?]

My understanding it there is no concept of _GNU_SOURCE version, as for
_XOPEN_SOURCE for instance. And I am not sure how useful would be to 
start using this concept, since nowadays programs that use _GNU_SOURCE
does not set it to a particular value.  

I am not aware of any changes being planned to support POSIX.1-2017,
neither if it would require additional FTM (afaik there is no need). 
If it were the case, it might be require to discuss to how handle it 
in along with _GNU_SOURCE.

> 
> I note that:
> 
> Â  -D_DEFAULT_SOURCE -D_POSIX_C_SOURCE=200112L
> 
> throws away the given _POSIX_C_SOURCE and forces 200809L.  (So that's similar to _GNU_SOURCE.)
> 
> But I also note that:
> 
> Â  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600
> 
> does not throw away the _XOPEN_SOURCE, and the result is _POSIX_C_SOURCE 200809L with _XOPEN_SOURCE 600, which is undefined :-(
> 
> I'm pretty sure that's a bug !

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

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

GLIBC current behaviour is just assume the most recent one, which I think
it is reasonable. Either way, I see no point or changing this semantic
(to assume lest recent one) or to dump either errors or warning for the
case of mismatched selection.

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