Quantcast

_XOPEN_SOURCE

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

_XOPEN_SOURCE

Bryan Henderson
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?

--
Bryan Henderson                                   San Jose, California

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

Earnie Boyd
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

--
Earnie

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

Keith Marshall
In reply to this post by Bryan Henderson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20/04/17 16:32, Bryan Henderson wrote:
>> 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?

I've already cited the reference, for the current POSIX.1 specification;
every version of POSIX.1, which I have ever seen, uses fundamentally the
same wording (paraphrased):

  A conforming application shall ensure that _XOPEN_SOURCE is defined
  with the value n00 before including any header.

with 'n' representing the POSIX.1 issue number, and 'shall' indicating
that the requirement is mandatory.

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

They are tolerant of applications which seek to be non-conforming; I
could, of course, show equal tolerance, but I am loathe to encourage
such non-conformist behaviour.

I would also emphasize that, in the case of MinGW, an appropriate
definition of _XOPEN_SOURCE will never achieve _full_ conformance to
any version of the X/Open standard, since only a small subset of it
is actually supported; if you expect otherwise, you will surely be
sadly disappointed.

- --
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+hrCAAoJEMCtNsY0flo/tlkP/3vFadVyNVSfN3j4bc64v9g1
YMoOy2fY6+1zr8Wmd5VZyzdPVNS50f9O/DXUdPCjBcFYfhnbxeujVy7vLGCSHeCX
38UOibG0ZSEVAiisXkmSz6GJSyYIVkQv9G1ZyJncSSOHutZ9RLP5U2wyaIAfHL2I
sZkAwrrRMMny0SStsDuip3p56WKAGAs36Feak+gvqAEvr31y7Zer/S6LP+HiBKzz
KN30r701fVC9r03A7MBgHr5HF9JrezfKAHntmRs/ppbqMJE5CUMPopt7CZqbTMe5
g96VTVdRMcuFlpRbL0v4dPhNuuzEIjDYMx+ZABQDtsmizQazPe2IARfSVRmV7enC
O00ztMScnsYPB6yaJYOysvXIxZCWJ40fTj/+T2040MnxSQRY5XMtBt8l5iHJ40Yw
c4O6+cHMftBAWNs3a5HOoy3p5FHaQ7XpZcdJ9o0NuzGFCX4KrmeKjL7wZLZaXObG
oNECLz4OuN2l1qQ7hv5dbqtVVPtnmNcOO45+xyegK5vZlaZ6rZCE3PaAA9SO6845
o8FxD53KpHzHJH7FVuJ4y38PiN+Hzakv5DV/Pd14iY8h+k3MmcaVUHbYZlTCS6j9
pPBgNTa9vozMhr0HXzQCmHZmnMa2q433LINyoZ12gIzf4Nua3Bwce5nzfeUlwgwB
aICT6/tp6zVG2AFbtOH8
=Dk1d
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

Keith Marshall
In reply to this post by Earnie Boyd
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
                   ^

- --
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+iYdAAoJEMCtNsY0flo/qbQP/3aaSy3U0UyhWqACGCi3wgiy
geFKtte5hVWRRcMpgRrnh2Yqto78rQaZ+SYrohOfWHlDNaYqbXvBZdokPKMadvQl
dgXTq+v+odqYev/G5IA47GFCQ4NUOWT3Anq9vOUsnCCvU42q692kMRU/BkCC+YUE
dQ8lyXDyZNFniV7rJDzMwosPa1TzIxfxDbTHFkU7MkzEt8qV4nVzOGsZypB96wEm
filkCjRRMhkYUnSyUyofd7k1prjM3r/aZnIisVgzxhYU8OMpKazINLAN+6m6viNW
Z0YVuBpRvs2TphPtCzjVOFWOiXJrNgcrapFOgj/rOoLoTR/EQP91y2yVUpKDzTgy
JkdoRvnnDSqdzt7cYdi4YNtldkGRxsrZfIXebGgjUWzjJw6fUXfadflHGB+Lywus
L19Sgv2EFQ8jjEiBUgWqlahfrR8eL8KJ7I8gS92gXUNiqOBBLDT/vNA9JC1UYPF4
xoTKN7/qYj4PThBBuuUWEhJ5VgwWBoWv2pWhd27f06rRobXy37hPu1VfEWrNk5MV
XQ2hVRdtCcumcIUqNluTW7csJYbM25dhLK2WTcG4r7Q79yHnTPeLf9gARbCskZA7
s8/2G5ua3irUvmL1rPyGlbszJZm7Rxw6Ag/YOKWQF8ei8s+YiYaxa9gzM/3YyJA4
UQIC3XiO3k94qS0Fp1aW
=ez2N
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

Earnie Boyd
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.  However, here
is another reference [2] indicating that _XOPEN_SOURCE may be defined
without a value prior to version 500.

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.

Given that GCC itself doesn't manage without a value I would suggest
that the correct fix is to assign a value.  The user will get further
with defining a value since there appears to be precedence for such
definition from the compiler authors.

[2] http://docs.oracle.com/cd/E19253-01/816-5175/standards-5/index.html
[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

--
Earnie

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

Keith Marshall
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

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

On 22/04/17 11:28, Keith Marshall wrote:
> ... 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.

Possibly by adding something like the attached to <_mingw.h>, before
any other reference to _XOPEN_SOURCE?  (Yes, it is pretty verbose in
its criticism of obsolete usage, but then, we want it to be so, don't
we?  It does seem to DTRT, for me).

- --
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+1RsAAoJEMCtNsY0flo/uLoP/Amz+wOdKOXarKbdzoK/M5lT
rTCjRf4foAqmoG1Ae/pUqePh65AMKRdJetUIpJmbszeaZzbBJyEJJd0mc9ZiQ1bt
UxmMMGlFNPdQUUMeeTfwD1CEFTxA0y6obIAEpCBSilZX7aYwaVfDCaRUzCi+yabJ
7io7eZljKATZA1Ue/OQwbFfSUmQ27Mw45aQqvrYwv/sSKJQfZNz9QJ7ISsB3Cdw/
BDXrxIXAAb8ApmnHBDNWdgNhSypn9h0bjZx5g3U8meNzvUiwI6NoTkXrhJM4YuPM
IrNHy3GgrlVL4zRxUsD6v2d/WGIA7cxmKNMeY2E65w7MAq3mkXhKvo6p7WxhZm3e
+N4YDPwQ3TS4U1QC+g4IdaoX7rVeJ8IrMAx1ZGoI73esRcg974yG4hh0U9hb5KBw
9Z/fotASpUf6omM+vcjR/XChsWONIJDazgP/aVQEiyvGh+zO6JXYS4FMmOvtujJl
l6E24CP5U9ss3Il6pu3PeeFXn/oUR4tVq44VKEDIH4+tVBE2U1LlWzLVXMrwn/v0
QyvVIhvJgaO/zQ2psemCbnXG8wxBLdk83NIlaRDynBB/0z+THB1DofgaKEIqkzKV
Q6QA2JdkqurqrOHreCMc3KOLz7/QldkiN8+0O6IUS/P0mLEYWTkU46PLbWSUefGR
UEnprtjKZ+34/zZzm4H4
=fKyG
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe

xopen_source.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

Bryan Henderson
In reply to this post by Earnie Boyd
>bar.c:2:19: error: operator '&&' has no left operand

I wonder how you get that.  I was unable to reproduce it.

I invoked Gcc 4.9.2 with no options except -c.  I also tried Gcc 2.95.3.

I'm not sure it really matters; the man page isn't claiming that's literally
the code in the library.

--
Bryan Henderson                                   San Jose, California

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

Bryan Henderson
In reply to this post by Earnie Boyd
>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.

This Linux Programming Reference is consistent with the others.

  #define _XOPEN_SOURCE

does define the macro with a value - null string.  All defined macros have
values, and the book is just telling you it doesn't matter which one you set.
If you look at how the book describes the other feature test macros, such as
_BSD_SOURCE, which never had any version number variants, you see that "with
any value" does not imply a non-null value or a numeric value.

--
Bryan Henderson                                   San Jose, California

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

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

On 23/04/17 18:27, Bryan Henderson wrote:
>> 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.
>
> This Linux Programming Reference is consistent with the others.
>
>   #define _XOPEN_SOURCE
>
> does define the macro with a value - null string.

It does no such thing ... null string is explicitly "".  You are defining
it to represent nothing at all, and that is a violation of POSIX, as of
POSIX.1-1996 (SUSv2).  Your usage is long obsolete ... time you woke up
to life in the 21st century, and updated 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/QC9AAoJEMCtNsY0flo/shQP/RsDaW0DWg6Hpz7mj+SwByRv
FXgdfp+UN4UkNJ2ki9cyK6aNPEnJwolKK2Gy6cLj4UTGEQXhzG6dvsuSNKwWq32M
PFgchj+91cyO6IUTL6evboXQR5NHF502mFrL7FxplPFe+M+lvS5dfFwNrqO2SFy7
Jp05alL9pxToZTWwJkRedBz/vrQnHfdXW1FUxf1Ehu/xczwwy6PHJ8qLc4rPlfNc
22tdst96BnMDrNaFzyV3wRhmsjeusO7SM7Am3Wha2VxbOdX9VK5cfx3AZ6QfW+7a
qngi40c6z8BDiqtaknSRwfw3PjdJe/HyUmB7Wo7bWSvHjKiy1ERP6GIz8oz18REH
cCMYgCzjZngV8mvaJqsnjjJI8YgOvDep8o3meSQtv47TsFPQmdjIwNzB4t0ob39L
cBOCSsL9g1MWzWG7nRds58RY1RWE9C8Dd0mHK1ARezxP0TaOeUXE7fb6pPZM74O4
v8c6JE0NhKFveChhfPRcy9pUnrK1pD9H3VJEQfUPuU15d+F5NeLXcLysEvwCLfkI
cUoTPbbcaNxmaiml7d/DW36ggMNjrJlSs2beDDtgExiMQyLYCX/9ZAyRBSbMIJD6
6BuEZcw4qB20VNjp/i9mGsxx7WxxGcsqUJqyOkrHpuzuOVPokaitChFrXEG7Nlkn
pIQ+xmUQhSgYR6FSsQjV
=QzYL
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

Keith Marshall
In reply to this post by Bryan Henderson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23/04/17 18:15, Bryan Henderson wrote:
>> bar.c:2:19: error: operator '&&' has no left operand
>
> I wonder how you get that.  I was unable to reproduce it.

Simply, by reproducing the example guard from feature_test_macros(7):

  $ cat foo.c
  #define _XOPEN_SOURCE
  #if defined __BSD_SOURCE || (_XOPEN_SOURCE && _XOPEN_SOURCE < 500)
  #endif

  $ gcc --version
  gcc (Debian 4.8.2-1) 4.8.2
  Copyright (C) 2013 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.
  There is NO warranty; not even for MERCHANTABILITY or FITNESS
  FOR A PARTICULAR PURPOSE.

  $ gcc -c -fsyntax-only foo.c
  foo.c:2:44: error: operator '&&' has no left operand
   #if defined __BSD_SOURCE || (_XOPEN_SOURCE && _XOPEN_SOURCE < 500)
                                            ^

  $ mingw32-gcc --version
  mingw32-gcc (GCC) 5.3.0
  Copyright (C) 2015 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.
  There is NO warranty; not even for MERCHANTABILITY or FITNESS
  FOR A PARTICULAR PURPOSE.

  $ mingw32-gcc -c -fsyntax-only foo.c
  foo.c:2:44: error: operator '&&' has no left operand
   #if defined __BSD_SOURCE || (_XOPEN_SOURCE && _XOPEN_SOURCE < 500)
                                            ^

- --
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/QmSAAoJEMCtNsY0flo/BpYP/1W1QS+zYjI1z/bdHdZDEsp4
+PRb+DPPDUonvYpCOJum/eEg41IfydbqR8w7wxqI5OnbnzpdEPygSdf36GMvGCbe
F9CsPZVj6TAz/kEeKh9PI4lIk2sZdnJq7JrDQdO502SScGiUApefWZVMI1mIFPZ3
Czz1Ph92G8X5xOj5SKpUpbpUF3GA1/rOzKFW3VDUIm/9P1H7WyvbI5TDd8l8ilmx
ccl1BnIRtoAzqnUbJwwamUWgAtqx6u3isy7yh9QrXB2e6CIhdqH4O8DftRN4Scyv
vP8CioqZGWkliEGjzzY7/S2/tx/kntMyyLtQzIJWtqC2PMGszeehTdKfV1kGIv4u
KfJxOrH5qpU0cSuLMfTEusnXNjGdDu9vjw3fYJ/3nJPiO5gxWl5nFYKi+PK9dm0c
/xnE7bLLjwVROGvry36ZnTTnJ7RHj4aXpWELEKfChkB6xvChmSR7m+7TQ1Ytnfgt
isL7NUOZN/YWwU7JDqoalnOiSak7kBAr0OkJtagpIrMFbq/e+XjEDwg4mlm+aoEF
WX09ZnHWkB1qHC6kpYPJVwAMAtQ/UqABJDxV9RZUmzvmpWlO5m4vn/9xQ6+oGWRt
8turuK0ZfsLPIWYHUVg10plMRKOADKTYYSpSd7JQv5fWZaNG7hb7loX/+IRHhoqP
QboKFWLVxB93SZGPJqDW
=YpyE
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

Keith Marshall
In reply to this post by Bryan Henderson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23/04/17 18:15, Bryan Henderson wrote:
> I'm not sure it really matters; the man page isn't claiming that's
> literally the code in the library.

Maybe not, but it *does* imply that a specific syntax should work, and
that isn't the case with your long obsolete _XOPEN_SOURCE usage.

- --
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/Qq8AAoJEMCtNsY0flo/foYQALFMXzS4VcOa22Y1xsO6DJTF
kRMTMTH0wXaKHHOx/3xviZTAdVDzIQ+PcwScvUffgH1q2BousuXr4QTsICGOHO56
oOq+/4QD7RGCjQ9tqrXbTSsI98YONTE7ywibUJMvlvwaw2KmPA0VRkOMQEmBHiT2
26XD0NG800FXcRan482X1E8Y3OEapOqZT5nAFwuwK0sUHz0gB7sTNY8KlDuojYag
rHuaZqJ65j1aXsJHwSwXZnSK8w6w3hMyFJm0OCzI3ywynF8p1KYt09AKYCK21V9k
sMJD9FU6JxoK+mElhzW9QwHSBi/GhgTzVI0KlDZzz5PPkp6N6piiDxPpaIZpVL4F
RsVY+E5NsW4pPEeRw7EzBC2C/D5G5bpmFdQ+rxIPtyoPUiuEHxfukD1RxNQ7R6dV
F0ZZiBsYBrazS4qh/0D70KBWggP08AgXXCyzEy8dQs+xTWxlnh2iuIx2+4adIZyU
AIXycZk3+kDn4ifcZUJIlHVMeg/eqhO+8rSTdNAv4UUpeAI1P5WS/6xov/PqXG2V
vtQFClOccG/7VLfRoU+/qoR8m8GrrvBnXxo4YtR/o9SnBUWpngF1iTcRFQfDwxQ5
j3jT6ml9hsgpFkTUA9E9ybDJPb2PM/KunAxh+pdOSvuPQ/80I+dE9oefadB+UYR3
Yj+YhNJP/d8m4/SUvHew
=YcXB
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

Bryan Henderson
In reply to this post by Keith Marshall
>It does no such thing ... null string is explicitly "".

OK, it was a mistake for me to use the word "string," since it has a specific
other meaning in the C language.  I should have said null value or zero-length
value.

But there is no concept in the C macro language of a macro with no value (I
think the technical term is "expansion") at all.

And in case there's any doubt that the author of the Linux Programming
Reference meant to include the zero-length value in the phrase "any value," as
I said before, you just have to look at the other places he uses it on the
same page -- In reference to situations where no one in the history of C
programming has ever #defined a macro with anything but a zero-length value.

--
Bryan Henderson                                   San Jose, California

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

Bryan Henderson
In reply to this post by Keith Marshall
>> I wonder how you get that.  I was unable to reproduce it.
>Simply, by reproducing the example guard from feature_test_macros(7):

OK, I see the same thing now.  I don't know what I was doing yesterday.

--
Bryan Henderson                                   San Jose, California

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

Earnie Boyd
In reply to this post by Bryan Henderson
On 4/24/2017 11:09 AM, Bryan Henderson wrote:

>> It does no such thing ... null string is explicitly "".
>
> OK, it was a mistake for me to use the word "string," since it has a specific
> other meaning in the C language.  I should have said null value or zero-length
> value.
>
> But there is no concept in the C macro language of a macro with no value (I
> think the technical term is "expansion") at all.
>
> And in case there's any doubt that the author of the Linux Programming
> Reference meant to include the zero-length value in the phrase "any value," as
> I said before, you just have to look at the other places he uses it on the
> same page -- In reference to situations where no one in the history of C
> programming has ever #defined a macro with anything but a zero-length value.
>

You need to update your reference material.  I'm assuming that your
"Linux Programmer's Reference" is Richard Petersen's book from 1999.
I'm a correct?  If so the book was obsolete the day it was produced as
things change so fast in our world that only the most current references
count for anything concrete.  If not, please provide a better reference
than just a title.

--
Earnie

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

Bryan Henderson
>You need to update your reference material.  I'm assuming that your
>"Linux Programmer's [Programming] Reference"

I misremembered the name, and relied too much on context.  This subthread is
about The Linux Programming Interface by Michael Kerrisk, which you cited in
support of the proposition that source code should not define _XOPEN_SOURCE
with a zero-length value.  I'm pointing out that you misread that reference
and the author actually intended the opposite.

https://sourceforge.net/p/mingw/mailman/message/35800258/

--
Bryan Henderson                                   San Jose, California

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

Earnie Boyd
On 4/25/2017 11:22 AM, Bryan Henderson wrote:

>> You need to update your reference material.  I'm assuming that your
>> "Linux Programmer's [Programming] Reference"
>
> I misremembered the name, and relied too much on context.  This subthread is
> about The Linux Programming Interface by Michael Kerrisk, which you cited in
> support of the proposition that source code should not define _XOPEN_SOURCE
> with a zero-length value.  I'm pointing out that you misread that reference
> and the author actually intended the opposite.
>
> https://sourceforge.net/p/mingw/mailman/message/35800258/
>

"If defined (with any value)"

If the author intended that an empty reference was valid he would not
have added "(with any value)".  An empty reference does not expand to a
value so it is therefore not valid for this macro to be defined as such.
 It is the expansion of the macro that matters and an expansion that
causes the use of the macro to result in errors in system headers is not
a valid value.

--
Earnie

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

Bryan Henderson
>"If defined (with any value)"
>
>If the author intended that an empty reference was valid he would not
>have added "(with any value)".  

I don't know what you mean by empty reference, but

  #define ABC

defines a macro ABC with a value witch is zero characters.  It is common to
refer to that entity as a value; every programming language I know that has
a data type for text defines zero characters as one of its possible values.
The author said "any value" to let you know that it doesn't matter what value
the macro has, even the zero-character one.

But again, if you think the author might have considered zero characters not
to be a value, you have only to look at how he used the phrase "(with any
value)" elsewhere on the same page to know that it didn't.

As you're probably aware, other feature test macros, such as _BSD_SOURCE never
assigned any meaning to particular values, and therefore people essentially
always define it as the zero-character value.  It's the most logical value to
use when any value works.  And yet, this author said _BSD_SOURCE can have "any
value".

This author knew that all C libraries at that time would accept any value,
even the zero-character one, for _XOPEN_SOURCE too.



--
Bryan Henderson San Jose, California

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

Earnie Boyd
On 4/25/2017 8:20 PM, Bryan Henderson wrote:

>> "If defined (with any value)"
>>
>> If the author intended that an empty reference was valid he would not
>> have added "(with any value)".  
>
> I don't know what you mean by empty reference, but
>
>   #define ABC
>
> defines a macro ABC with a value witch is zero characters.  It is common to

That is where you are incorrect.  Macro expansion expands this to no
value.  It is not the same as an empty string represented by "" which as
zero characters.

> refer to that entity as a value; every programming language I know that has
> a data type for text defines zero characters as one of its possible values.
> The author said "any value" to let you know that it doesn't matter what value
> the macro has, even the zero-character one.
>

Any value is not to be construed to mean an empty definition which can
only be tested with the defined() macro function.  An empty definition
expands to nothing and constructs where a value is expected cannot be
properly compiled when the definition is empty.

> But again, if you think the author might have considered zero characters not
> to be a value, you have only to look at how he used the phrase "(with any
> value)" elsewhere on the same page to know that it didn't.
>
> As you're probably aware, other feature test macros, such as _BSD_SOURCE never
> assigned any meaning to particular values, and therefore people essentially
> always define it as the zero-character value.  It's the most logical value to
> use when any value works.  And yet, this author said _BSD_SOURCE can have "any
> value".
>

I caught this after I sent my previous email but did you read the the
first paragraph on the next page explaining that _XOPEN_SOURCE is
expected to have a value?  I'm not sure why the author decided to
convolute what he was describing by adding "(with any value)" to those
not requiring a value.  An empty definition isn't a value and can only
be used as a filter with the defined() macro function.

> This author knew that all C libraries at that time would accept any value,
> even the zero-character one, for _XOPEN_SOURCE too.

Again, a zero character value is not the same as an empty definition
where the expansion of a macro is nothing at all.

--
Earnie

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: _XOPEN_SOURCE

Bryan Henderson
It occurred to me that we're not just talking about the computer science
concept of the null string, but the very concept of zero.  It can be argued
that zero is not a number, and as I understand it, people did arithmetic for
millenia without recognizing such a number.  If you have no apples, the
question "how many apples do you have" is not answerable.  Yet, zero is so
useful that we're all used to it such that if you asked someone to write down
the number of apples he has, he would feel completely justified in writing
zero.

So you have a real uphill climb in demonstrating not only that the null value
is not a value in C macro language, but that the author of the book we're
talking about held that view.  I know you can't find any reference for the
idea that a macro can have no value, and I probably can't find anything that
explicitly says the null value is a value.  (Unfortunately, my brief look at
manuals tells me that the term "value" isn't even used in technical
discussions, so this is just a generic term we have to interpret).

>It is not the same as an empty string represented by "" which has
>zero characters.

That's the C language.  We're talking about the C macro language, where
quotation marks have no special meaning.  "" in the C macro language is a
2-character value.  The only way to give a zero-character value to a macro is
to put zero characters in the body part of the #define statement.

One thing I haven't pointed out yet is the importance of the fact that
"(with any value)" is a parenthetical expression.  That means the sentence is
correct without it.  I.e. "If defined, expose ... definitions".  Doesn't
matter what you define it to, just define it.  The parenthetical is very
helpful, though, because if the author had left it out, a reader would say,
"Define it to _what_?  A macro has to be defined to _something_.  Finish
the instruction."  It would not be obvious to a reader that the library is
just doing an #ifdef and the value doesn't matter.

>did you read the the first paragraph on the next page explaining that
>_XOPEN_SOURCE is expected to have a value?

It says it is expected to have a value to conform to certain standards.  That
has never been in question in this thread.  The original question, which I
believe you were trying to answer with this book reference, was have _all_ of
the X/Open (XPG, XSI) standards required a version number value for
_XOPEN_SOURCE.  Keith Marshall, who made the surprising original statement
that they have, seemed to be convinced otherwise later when he changed his
stance to, "we don't care to implement those old standards."

--
Bryan Henderson San Jose, California

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
12
Loading...