Problems with default _POSIX_C_SOURCE in features.h ??

[Chris Hall]

On 11/04/2019 22:40, Adhemerval Zanella wrote:
> On 10/04/2019 08:21, Adhemerval Zanella wrote:
>> On 09/04/2019 16:00, Chris Hall wrote:
>>> On 09/04/2019 18:42, Adhemerval Zanella wrote:
...
>>>> The main problem in my view is there is no guarantee from glibc for which
>>>> _POSIX_C_SOURCE _DEFAULT_SOURCE will define in the future for possible new
>>>> _POSIX_C_SOURCE values. I think it is worth a discussion and I will raise
>>>> this question on libc-alpha.

>>> My guess is that it will select the latest and greatest.
>>>
>>> Will anyone commit to it setting _POSIX_C_SOURCE=200809L forever ??
>>>
>>> Which leads to the problem that to enable XSI with _DEFAULT_SOURCE, you
>>> (currently) have to know which -D_XOPEN_SOURCE=xxx to use, and that
>>> depends on which version of the library is being compiled for.

>> As I said, there was not need to change it from original default of POSIX1.2008,
>> and I asked on libc-alpha which would be the idea for this flag [1].
>>
>> [1] https://sourceware.org/ml/libc-alpha/2019-04/msg00239.html

> It seems the current consensus is indeed that _DEFAULT_SOURCE would map to
> latest available POSIX1 standard [1].
> 
> [1] https://sourceware.org/ml/libc-alpha/2019-04/msg00244.html

OK.  If I want -D_DEFAULT_SOURCE plus the corresponding latest available 
XSI (on whatever version of library my users are compiling against), 
then I observe:

   1) -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=-1UL will do the trick
                                                  -- ugly, though.

   2) -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=700 does the job now...

      ...but will be broken in the future.

   3) a new _DEFAULT_XOPEN_SOURCE might be cleaner ?

>> It is possible that my worry is a symptom of ignorance.
>>
>> I have a large network application which is required to compile
>> for more or less any UN*X.  I develop and test on Linux.  I 
>> would like the minimum of surprise when compiling and testing on
>> other systems.
>>
>> Now, FreeBSD has caused me some trouble in the past.  ... 
...
>> So, I figured that on Linux, with glibc, I could:
>>
>>    -D_XOPEN_SOURCE=600 -D_BSD_SOURCE
>>
>> and that might approximate to FreeBSD, and other UN*X which more
>> or less conform to POSIX.1-2001 or are certified UNIX 03.
>>
>> But late model glibc won't let me do that
...
>> Perhaps I am, in any case, wasting my time ?  Perhaps the reality
>> is that I cannot avoid being caught out occasionally by differences
>> between systems... and I should just be grateful it's only 
>> occasionally.

> We can't really guarantee compatibility for _BSD_SOURCE in particular
> (specially because we don't aim to be fully BSD compatible). But we
> usually treat _POSIC_C_SOURCE an _XOPEN_SOURCE deviations from 
> standards as bugs (if you find some please open a bug report).

That much is clear.  As I say, my hope was to minimise surprises when 
testing on BSD-like systems.

...>> Of course, glibc encourages the use of _GNU_SOURCE, which selects
>> the latest and greatest _XOPEN_SOURCE.  But, it also enables all 
>> the GNU libc specials, which I really don't want.  It also seems 
>> to select C11 things, even if the compiler is not 
>> __STDC_VERSION__ 201112L, which I cannot say I like the look 
>> of, either.

> _GNU_SOURCE definitely does not enable C11 symbols. It relies solely on
> __STDC_VERSION__ value:
> 
> include/features.h:

   190 #ifdef _GNU_SOURCE
   191 #undef  _ISOC95_SOURCE
   192 #define _ISOC95_SOURCE 1
   193 #undef  _ISOC99_SOURCE
   194 #define _ISOC99_SOURCE 1
   195 #undef  _ISOC11_SOURCE
   196 #define _ISOC11_SOURCE 1

Forcing C99 for POSIX-2008 makes some sense.  But C11 should be skipped 
if __STRICT_ANSI__ ?

...> And I am not aware of any bug related to this. Are you sure we
> you are seeing it or are you using a compiler version that sets
> __STDC_VERSION__ as default?

The effect of __USE_ISOC11 is small (8 appearances outside <features.h>).

>> I'd like a way to select the latest and greatest _XOPEN_SOURCE
>> and/or _POSIX_C_SOURCE, while not selecting any GNU extensions.
>>  Perhaps, say, _XOPEN_SOURCE_LATEST and/or _POSIX_SOURCE_LATEST ?

or _XOPEN_LATEST_SOURCE and/or _POSIX_LATEST_SOURCE ?

>> [I guess I could require users to install glibc, and surrender
>> to the _GNU_SOURCE... but that doesn't feel right.]
>>
>> Suggestions, anyone ?

> AFAIK it should be exactly as POSIX recommends: 
> -D_POSIX_C_SOURCE=value and/or -D_XOPEN_SOURCE=value.

I should have said that I'd like a way to *automatically* select the 
latest and greatest _XOPEN_SOURCE/POSIX_C_SOURCE -- like _GNU_SOURCE does.

For a given version of glibc, past and future, what should my configure 
script do to determine the value to use ?  [_GNU_SOURCE appears to 
select the latest and greatest, but that's not explicitly stated in the 
documentation.]

Or should I use -1UL ?

If I simply set -D_XOPEN_SOURCE=700, then I will need to update the 
application when the next version becomes available.

Perhaps nobody really needs an automatic way to select the latest 
available ?  [Except, as noted above, to enable XSI stuff with 
-D_DEFAULT_SOURCE.]

Thanks,

Chris