Problems with default _POSIX_C_SOURCE in features.h ??

[Adhemerval Zanella]

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:
>>> On 09/04/2019 14:12, Chris Hall 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

> 
> 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.  Recent FreeBSD admits to POSIX.1-2001 (more or less), but denies X/Open.  If you compile *without* specifying any _XXX_SOURCE macros (_POSIX_C_SOURCE, _XOPEN_SOURCE, POSIX_SOURCE, _ANSI_SOURCE, _C99_SOURCE and _C11_SOURCE) then you get:
> 
>   #define __POSIX_VISIBLE  200809
>   #define __XSI_VISIBLE       700
>   #define __BSD_VISIBLE       1
>   #define __ISO_C_VISIBLE  2011
>   #define __EXT1_VISIBLE   1
> 
> which appear to select everything available, including some XSI things. But you also get:
> 
>   #define _POSIX_VERSION   200112L
>   #define _XOPEN_UNIX      -1
> 
> but _XOPEN_VERSION is not defined.
> 
> 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 really don't need -D_BSD_SOURCE (now -D_DEFAULT_SOURCE) with POSIX.1-2001 ?

My understanding is _BSD_SOURCE is a BSD-derived FTMs that glibc aims to
 only provide some compatibility support (we still lack a lot of common BSD 
common symbols, like strlcpy for instance; some kernels depends interface
are tricky to implements; and we do not really aim to be fully BSD
compatible).

It is deprecated since glibc 2.20 in favor of _DEFAULT_SOURCE and
pre-2.20 it used to enable __USE_MISC (as _DEFAULT_SOURCE currently).
It define things from 4.3BSD or System V Unix (things like some mmap
flags).

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

> 
> If so, I might as well compile for the latest and greatest _XOPEN_SOURCE, and trade the advantages of recent features against the (greater) risk of surprise.
> 
> 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:

225 /* This is to enable the ISO C11 extension.  */
226 #if (defined _ISOC11_SOURCE \
227      || (defined __STDC_VERSION__ && __STDC_VERSION__ >= 201112L))
228 # define __USE_ISOC11   1
229 #endif
[...]
243 #ifdef __cplusplus
244 /* This is to enable compatibility for ISO C++17.  */
245 # if __cplusplus >= 201703L
246 #  define __USE_ISOC11  1
247 # endif
[...]
254 #endif

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?

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