Re: [Mingw-users] _XOPEN_SOURCE
-----BEGIN PGP SIGNED MESSAGE-----
On 22/04/17 00:27, Earnie wrote:
> On 4/21/2017 11:32 AM, Keith Marshall wrote:
>> On 21/04/17 15:12, Earnie wrote:
>>> On 4/20/2017 11:32 AM, Bryan Henderson wrote:
>>>> Keith Marshall, in a recent thread:
>>>>> in _every_ case, the application is _required_ to specify the
>>>>> _XOPEN_SOURCE value for which conformance is desired.
>>>> Why do you say that? Common sense, or did you see it written
>>>> And what do you make of the fact that every other X/Open-capable
>>>> C library explicitly recognizes _XOPEN_SOURCE = null string as
>>>> meaning "source code expects C library to conform to the original
>>>> X/Open standard?
>>> This reference  supports Bryan's assertion.
>>>  http://man7.org/linux/man-pages/man7/feature_test_macros.7.html
>> Yet, the example it cites requires a definition _with_ a value, (and
>> moreover, a non-zero value); when preceded by:
>> #define _XOPEN_SOURCE /* no value */
>> GCC will complain:
>> bar.c:2:19: error: operator '&&' has no left operand
>> #if _XOPEN_SOURCE && _XOPEN_SOURCE < 500
> So that documentation is somewhat off as defining _XOPEN_SOURCE without
> a value could never be tested that way without an issue.
Exactly so. In fact that same document goes on to say:
| Defining [_XOPEN_SOURCE] with any value exposes definitions conforming
| to POSIX.1, POSIX.2, and XPG4.
this being the least inclusive permitted form of definition; note that
this implicitly makes definition with a value mandatory ... "with no
value" is _not_ the same as, nor included by, "with any value".
> However, here is another reference  indicating that _XOPEN_SOURCE
> may be defined without a value prior to version 500.
>  http://docs.oracle.com/cd/E19253-01/816-5175/standards-5/index.html
Yes. It took some finding, but in the interim I had also discovered
an alternative, but substantially similar reference for SunOS:
This does suggest that, prior to SUSv2, it may have been permissible
to define _XOPEN_SOURCE without a value; today, any such usage must be
considered _long_ obsolete ... even SUSv2 is now obsolete!
> This reference  indicates that _XOPEN_SOURCE should contain a
> value. So prior to SUSv3 it appears to be up in the air as to how the
> constant should be used; with versus without a value.
>  https://books.google.com/books?id=2SAQAQAAQBAJ&pg=PA62&lpg=PA62&dq=_XOPEN_SOURCE+prior+to+500&source=bl&ots=qQy-d8DBqz&sig=hJPPWeiUeH0uL4qLqXgyF2pwTQ8&hl=en&sa=X&ved=0ahUKEwiGsvSN1rbTAhWBbSYKHVL3AXUQ6AEIPjAE#v=onepage&q=_XOPEN_SOURCE%20prior%20to%20500&f=false
Well, to me that just appears to reiterate the Linux manpage.
> Given that GCC itself doesn't manage without a value I would suggest
> that the correct fix is to assign a value.
Yes, but doing so isn't _our_ responsibility! While our headers may
test it, the definition _must_ come from the application itself.
> The user will get further with defining a value since there appears
> to be precedence for such definition from the compiler authors.
Agreed. This is why I favour leaving <_mingw.h> as-is; maintainers of
affected applications should be encouraged to comply with the standards
which are applicable _today_, and these make it mandatory to define
_XOPEN_SOURCE _with_ an appropriate value. We shouldn't simply sweep
obsolete usage under the rug; if we _must_ tolerate it, then we should
at least devise a strategy for nagging errant maintainers about it.
Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
-----END PGP SIGNATURE-----
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
MinGW-users mailing list
This list observes the Etiquette found at
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
You may change your MinGW Account Options or unsubscribe at: