-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by EarniePost by Keith MarshallPost by EarniePost by Bryan Hendersonin _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 somewhere?
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 [1] supports Bryan's assertion.
[1] http://man7.org/linux/man-pages/man7/feature_test_macros.7.html
Yet, the example it cites requires a definition _with_ a value, (and
#define _XOPEN_SOURCE /* no value */
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".
Post by EarnieHowever, here is another reference [2] indicating that _XOPEN_SOURCE
may be defined without a value prior to version 500.
[2] 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:
https://docs.oracle.com/cd/E53394_01/html/E54776/susv2-5.html
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!
Post by EarnieThis reference [3] 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.
[3] 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.
Post by EarnieGiven 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.
Post by EarnieThe 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.
- --
Regards,
Keith.
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)
iQIcBAEBAgAGBQJY+zA5AAoJEMCtNsY0flo/MGMQAIP2WJ50nAzYwk7ZmFYQkfCm
CcWINMB7REYxKyw51DN/Kyh3Xeqc9C4v9dJQmQo4l/AOwygCRGn2n3V0BUSiPApJ
UoUQY79QZdt7Omni2xDZPqZQiPpaKGYoQg0WUrUoqIYrapLJHLu8bNIAc4yzkHEp
iNIbSce0vocCbBYkQlOuzXqOZmfpCvcGy0Qg2xQd2kLiN55DWsxHADtpcgH/CdcZ
kxpiNA4t7DTvJGt2sczTSiRVY0hQWtH+wXtdrSMBKyED2cXrOfpfe05/wsdyM/+d
jRb77uNZnZ5CC6GbnjDveUAM+vSFIOZO7cFCvD4q2wwr6+asl+SjnZvWhU4TwT0w
9A1ux9Mw3sm+i04SejUqqzMJhp9QYJY38vav8Z5kl47vvdZhJGxUDoH+djuivE87
r+QZ/7IOVfwU/a9nMfzS9bqRvg78EHG7u+qSCDFtsV+tIuzJvY7R60kklfW6Yv+v
7ohSnKyXTafrH3WRf1MxrsWamqUBhwD8r/do12cUckUYDqQxnoeFO2Jf/Te8xFMB
oywCMkysfRSD896GldpeitqHid+M7azatc1sFa3DgQD12WF6v2HqCbVRMHImVYDz
n1C5R3opHpj5ebfS5Av2u518LjtS9x793CR0d6bfHMDUASqBH+622U9TH8Wq6w6G
gSV1BZrJh/j7xX1k+HUb
=qsFm
-----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
MinGW-***@lists.sourceforge.net
This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe