Problems with default _POSIX_C_SOURCE in features.h ??
Adhemerval Zanella
adhemerval.zanella@linaro.org
Fri Mar 29 17:54:00 GMT 2019
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)?
More information about the Libc-help
mailing list