Re: Problems with default _POSIX_C_SOURCE in features.h ??

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 12/04/2019 11:07, Chris Hall wrote:
> 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__ ?

But the features defined internally by __USE_ISOC11 will only be available
if compilers defines the correct __STDC_VERSION__.  The idea of GNU source
is to enable the latest feature in par with compiler support.

> 
> ...> 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 really want to avoid *more* FTMs, since it is more permutations we need
to take care off, more tests we need to check, more documentation we need
to write and keep updated.  

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

My understanding is historically _DEFAULT_SOURCE was added as a compatibility
replacement over _BSD_SOURCE / _XVID_SOURCE (which were deprecated).  Since it
was meant as a replacement for already defines FTMs, adding XSI extensions 
might break programs and it is something we avoid. Unless one can actually
show that adding XSI extensions won't break things, I would rather avoid
changing _DEFAULT_SOURCE semantic. 

I think the issue is you are trying to assure compatibility using the wrong
tool: _GNU_SOURCE or _DEFAULT_SOURCE are *not* the option to assure build
compatibility over different libcs implementation.  Even we add 
_DEFAULT_XOPEN_SOURCE it would not be a complete and future-proof way to 
assure compatibility.  

My take is adding more FTMs to add the latest supported
 _POSIX_C_SOURCE and _XOPEN_SOURCE is not much gain and it would add more 
FTM permutation that would incur in just more internal complexity to handle
it.  However other maintainers might have a different view, so you might
try to raise it on libc-alpha.