Web lists-archives.com

Re: [Mingw-users] _XOPEN_SOURCE

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:

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.

- -- 

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
Version: GnuPG v2.0.20 (GNU/Linux)


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:
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe