Web lists-archives.com

Re: [Mingw-users] _XOPEN_SOURCE




-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

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

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

- -- 
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-users@xxxxxxxxxxxxxxxxxxxxx

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-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe