Re: [Mingw-users] _XOPEN_SOURCE
On 4/26/2017 11:43 AM, Bryan Henderson wrote:
> 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
> 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).
I will agree that the word "value" is vague and I've been trying not to
use it in my explanations to you.
>> 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.
You're separation of the macro language from the C language it supports
is a bit misplaced but yes there is a stated syntax for the macro parts.
You've also taken my statement a bit too far in that I was just making
a comparison of an empty macro define is not the same as a C string of
"". Within the macro language an empty define has the value of defined
but expands to nothing. Within the macro language a macro can be
expanded within the use of another macro or expanded in the use of a
filter. However with such use the macro must expand to something and an
empty define cannot expand into something.
> 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.
A valid assumption by the author would be that the reader has some
experience with the C language. So your assumption that the reader
would have such a question or misunderstanding is a bit presumptuous.
>> 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."
Which is to say you must fix your use of _XOPEN_SOURCE.
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: