comp.lang.c - 25 new messages in 8 topics - digest

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* C progreamming - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/fc9113386afdfc9b?hl=en
* same struct, but different size. - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/fa87400135aae641?hl=en
* lvalues and rvalues - 6 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/0bcad112a3ad97f0?hl=en
* C the complete nonsense - 6 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/fee08dfa5e4cbaaa?hl=en
* Question about void - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/7cda9a8237a38531?hl=en
* seebs/schildt I - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/9f0200c489f848f8?hl=en
* Test of a preprocessor symbol defined as nothing vs. zero - 3 messages, 2
authors
http://groups.google.com/group/comp.lang.c/t/8e4236bf3f19c661?hl=en
* The allocator object - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/bee2ed48d0020c5f?hl=en

==============================================================================
TOPIC: C progreamming
http://groups.google.com/group/comp.lang.c/t/fc9113386afdfc9b?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 11:39 am
From: ike@localhost.claranet.nl (Ike Naar)

In article <fbd1d181-6c20-451a-9be2-29e4ae370e45@i25g2000yqm.googlegroups.com>,
saif raihan <saifraihan.lc@gmail.com> wrote:
>I am Saif Raihan. Ihave a question:
>" What is String?"

You will find useful information in chapter 8 of the C FAQ:
http://c-faq.com/~scs/cclass/notes/sx8.html

==============================================================================
TOPIC: same struct, but different size.
http://groups.google.com/group/comp.lang.c/t/fa87400135aae641?hl=en
==============================================================================

== 1 of 4 ==
Date: Sat, Apr 10 2010 11:50 am
From: Eric Sosman

On 4/10/2010 1:25 PM, Seebs wrote:
> On 2010-04-10, Control Freq<nick@nhthomas.freeserve.co.uk> wrote:
>> I see that a struct is defined a the top of two files, unit1.c and
>> unit2.c .
>> But, the struct has the same name, but the struct in unit2.c has more
>> elements.
>
>> A function in unit2.c takes a pointer to the struct as an arg, and the
>> function is called from unit1.c .
>[...]
>
> Also, warn the people in charge (management or whatever) *NOW*. Warn them
> that the program is dangerously badly written at a level that implies
> massive failure to understand C, and that any estimates they have for how
> long things will take are going to be too short. They may not like hearing
> it, but you might as well tell them in advance.

In defense of the original implementors, the program may
not have been "badly written" to start with. Large code bodies
frequently contain pieces from independent agencies, and C does
almost nothing to help separate colliding names. You've got a
big batch of code that defines and uses a `struct jabberwock',
and you decide to incorporate a spell-check library licensed
from Spelitrite and a Pantone color-management library from
Puceworks, and lo! each of these libraries also happens to define
a `struct jabberwock' for *its* own use. So now you've got three
incompatible `struct jabberwock' definitions floating around in
the code, and you're faced with the problem of making sure no two
of them ever bump into each other ...

... and someday, inevitably, some programmer says "I've got
a `struct jabberwock' and I need to gyre it, and -- Hey, look!
There's a `void gyre(struct jabberwock*)' function right here,
already written, and all I need to do is call it!" Things slithe
downhill right rapidly after that -- but it's no one's fault,
really.

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 2 of 4 ==
Date: Sat, Apr 10 2010 11:59 am
From: Control Freq

>
>      In defense of the original implementors, the program may
> not have been "badly written" to start with.  Large code bodies
> frequently contain pieces from independent agencies, and C does
> almost nothing to help separate colliding names.  You've got a
> big batch of code that defines and uses a `struct jabberwock',
> and you decide to incorporate a spell-check library licensed
> from Spelitrite and a Pantone color-management library from
> Puceworks, and lo! each of these libraries also happens to define
> a `struct jabberwock' for *its* own use.  So now you've got three
> incompatible `struct jabberwock' definitions floating around in
> the code, and you're faced with the problem of making sure no two
> of them ever bump into each other ...
>

Hi Eric, you described it just right.
Perhaps you were one of the original developers? There is actually a
pantone colour management library in there! But not by the same name.

Regards

Nick

== 3 of 4 ==
Date: Sat, Apr 10 2010 12:19 pm
From: Eric Sosman

On 4/10/2010 2:59 PM, Control Freq wrote:
>>
>> In defense of the original implementors, the program may
>> not have been "badly written" to start with. Large code bodies
>> frequently contain pieces from independent agencies, and C does
>> almost nothing to help separate colliding names. You've got a
>> big batch of code that defines and uses a `struct jabberwock',
>> and you decide to incorporate a spell-check library licensed
>> from Spelitrite and a Pantone color-management library from
>> Puceworks, and lo! each of these libraries also happens to define
>> a `struct jabberwock' for *its* own use. So now you've got three
>> incompatible `struct jabberwock' definitions floating around in
>> the code, and you're faced with the problem of making sure no two
>> of them ever bump into each other ...
>
> Hi Eric, you described it just right.
> Perhaps you were one of the original developers? There is actually a
> pantone colour management library in there! But not by the same name.

No way to know for sure whether I was one of the developers
of the unnamed piece of software you're dealing with -- but most
likely I wasn't, because there's a huge amount of software and
I've written "less than" ten percent of it ... It's a familiar
problem in C, though, when pieces from disparate sources are glued
together.

As for the Pantone stuff, I just chose that as an example of
the sort of thing one might very well license from a specialist
vendor rather than try to develop from scratch. I *did* once work
for a company that licensed both a Pantone library and a spell-
checker (and a few other things) from outside sources -- and had
exactly this sort of "integration problem" with them.

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 4 of 4 ==
Date: Sat, Apr 10 2010 12:47 pm
From: "Liviu"

"Control Freq" <nick@nhthomas.freeserve.co.uk> wrote...
>
> I see that a struct is defined a the top of two files, unit1.c and
> unit2.c. But, the struct has the same name, but the struct in unit2.c
> has more elements.
>
> A function in unit2.c takes a pointer to the struct as an arg, and the
> function is called from unit1.c .

What's been already said is correct - this is bad and dangerous.

> Now, I think that this is a bug, because the struct is in two places,
> and of two different sizes, and when the function is called, the
> program crashes.

As for the "crash" or not part, it somewhat depends on what
exactly you meant by "has more elements" (in particular whether
the leading elements in both structures match) and the internals
of the function being called. It is technically possible to have...

struct A { int b; }; // unit1.c

struct A { int b, c; }; // unit2.c
void setAb(struct A *a, int n) { a->b = n; }

...and call setAb from unit1 with an A pointer without ill side effects.
It would even be legit if the pointer was originally obtained from some
other function in unit2, albeit terribly poor design. But then I've seen
stranger things with C code trying to mimic C++ inheritance ;-)

Liviu

==============================================================================
TOPIC: lvalues and rvalues
http://groups.google.com/group/comp.lang.c/t/0bcad112a3ad97f0?hl=en
==============================================================================

== 1 of 6 ==
Date: Sat, Apr 10 2010 11:53 am
From: Eric Sosman

On 4/10/2010 12:34 PM, Tim Rentsch wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid> writes:
>> [...]
>> Here's a challenge: If an int* does *not* address the first
>> byte of an int object, can a portable[*] program detect the fact?
>> [snip explanation of "portable"]
>
> This question has no answer because it has no meaning. [...]

Very good! You've grasped my point, exactly!

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 2 of 6 ==
Date: Sat, Apr 10 2010 11:56 am
From: Eric Sosman

On 4/10/2010 12:49 PM, Tim Rentsch wrote:
>
> If we have
>
> int x[10][20];
>
> then 'x[y]' is not an lvalue.

No, it *is* an lvalue (assuming a valid `y'). It's not a
"modifiable lvalue," but it's an lvalue. 6.3.2.1p1.

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 3 of 6 ==
Date: Sat, Apr 10 2010 12:06 pm
From: Tim Rentsch

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> On 4/10/2010 12:49 PM, Tim Rentsch wrote:
>>
>> If we have
>>
>> int x[10][20];
>>
>> then 'x[y]' is not an lvalue.
>
> No, it *is* an lvalue (assuming a valid `y'). It's not a
> "modifiable lvalue," but it's an lvalue. 6.3.2.1p1.

Surely you must know what I mean. The expression
'x[y]' is an array and as such it is converted to
a pointer to the array's first element and is no
longer an lvalue. 6.3.2.1p3.

== 4 of 6 ==
Date: Sat, Apr 10 2010 12:54 pm
From: Keith Thompson

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>> On 4/10/2010 12:49 PM, Tim Rentsch wrote:
>>>
>>> If we have
>>>
>>> int x[10][20];
>>>
>>> then 'x[y]' is not an lvalue.
>>
>> No, it *is* an lvalue (assuming a valid `y'). It's not a
>> "modifiable lvalue," but it's an lvalue. 6.3.2.1p1.
>
> Surely you must know what I mean. The expression
> 'x[y]' is an array and as such it is converted to
> a pointer to the array's first element and is no
> longer an lvalue. 6.3.2.1p3.

That conversion isn't always done.

Expressions never appear in isolation. Even in the statement
x[y];
the expression ``x[y]'' is part of an expression statement. There's
always some context, and that context determines whether or not the
conversion takes place.

Given the above declaration, if x[y] appears in a context in which
the conversion takes place, it's not an lvalue; otherwise, it is.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

== 5 of 6 ==
Date: Sat, Apr 10 2010 12:57 pm
From: Eric Sosman

On 4/10/2010 3:06 PM, Tim Rentsch wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid> writes:
>
>> On 4/10/2010 12:49 PM, Tim Rentsch wrote:
>>>
>>> If we have
>>>
>>> int x[10][20];
>>>
>>> then 'x[y]' is not an lvalue.
>>
>> No, it *is* an lvalue (assuming a valid `y'). It's not a
>> "modifiable lvalue," but it's an lvalue. 6.3.2.1p1.
>
> Surely you must know what I mean.

Apparently not. I mistook your "`x[y] is not an lvalue"
to mean that `x[y]' is not an lvalue. Sorry about that.

> The expression
> 'x[y]' is an array and as such it is converted to
> a pointer to the array's first element and is no
> longer an lvalue. 6.3.2.1p3.

... which has nothing to do with the lvalue-ness of the
expression `x[y]'. It talks of the non-lvalue-ness of a value
*derived from* that expression in some contexts (those not
covered by the paragraph's first phrase, which begins with the
telltale word "Except").

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 6 of 6 ==
Date: Sat, Apr 10 2010 1:21 pm
From: Tim Rentsch

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>> On 4/10/2010 12:49 PM, Tim Rentsch wrote:
>>>>
>>>> If we have
>>>>
>>>> int x[10][20];
>>>>
>>>> then 'x[y]' is not an lvalue.
>>>
>>> No, it *is* an lvalue (assuming a valid `y'). It's not a
>>> "modifiable lvalue," but it's an lvalue. 6.3.2.1p1.
>>
>> Surely you must know what I mean. The expression
>> 'x[y]' is an array and as such it is converted to
>> a pointer to the array's first element and is no
>> longer an lvalue. 6.3.2.1p3.
>
> That conversion isn't always done.
>
> Expressions never appear in isolation. Even in the statement
> x[y];
> the expression ``x[y]'' is part of an expression statement. There's
> always some context, and that context determines whether or not the
> conversion takes place.
>
> Given the above declaration, if x[y] appears in a context in which
> the conversion takes place, it's not an lvalue; otherwise, it is.

Quite right. I'd already responded on this point, in
my followup to SG, so I didn't bother saying it
again.

==============================================================================
TOPIC: C the complete nonsense
http://groups.google.com/group/comp.lang.c/t/fee08dfa5e4cbaaa?hl=en
==============================================================================

== 1 of 6 ==
Date: Sat, Apr 10 2010 11:59 am
From: Tim Rentsch

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> cri@tiac.net (Richard Harter) writes:
> [...]
>>> In short, the C standards are incomplete; they do not completely
>>> specify the interpretation of code.
>>
>> It is complete in this area. The Standard says specifically
>> that order of evaluation is "unspecified", meaning any ordering
>> that doesn't violate any other stated requirements is allowed.
>>
>>> One way to look at it is that
>>> the standards specify C as a family of languages, differing by
>>> implementation defined rules.
>>
>> Certainly that is one way to look at it. A better way (IMO) to
>> look at it, at least as regards evaluation order, is that C
>> is a single language with a non-deterministic semantics. One
>> reason for this is that an implementation need not make the
>> same choice about evaluation order from one expression to the
>> next, or even the same on the next compilation as this one.
>> And for evaluation order in particular, implementations are
>> under no obligation to describe or document what rules they
>> use to determine ordering in any particular circumstance.
>
> Did you really mean to use the word "non-deterministic"?

Yes I did, and in retrospect I may have been guilty of confusing
the issue, so let me explain further.

IME the word "non-deterministic" is used to mean one of three
different things, even though these different meanings are
related they're definitely not the same:

1. Certain algorithms or automata are described as being
"non-deterministic" to mean that, when confronted with
a choice, they make "the right" choice, or in another
way of explaining the behavior they make all possible
choices. A non-deterministic Turing machine doesn't
make a choice at random, it makes the "right" choice
or equivalently it computes in parallel all possible
alternative choices.

2. Sometimes "non-deterministic" is used to mean that
when confronted with a choice some particular choice
is made, but which choice that is is made "at random".

3. In the area of formal semantics in particular, the
term "non-deterministic" is used as an adjective
(often modifying the word semantics) to mean that
when a choice is confronted, some particular choice
is made but the semantics doesn't prescribe how
the choice is to be made. Implementing a formal
semantics that is non-deterministic could be done
by, eg, always choosing the first alternative,
always choosing the last alternative, choosing the
n%k'th choice of k alternatives on the n'th choice,
waiting for a cosmic ray and making a choice based
on the energy of the cosmic ray, etc. In some sense
meaning (3) is a generalization of meaning (2).

Since I have some background in formal semantics, I meant the
phrase "non-deterministic semantics" in the sense of meaning 3.
This meaning is pretty close to what the C standard calls
'unspecified behavior' (in fact probably identical, but I don't
want to equate a formal term and an informal term without a lot
more thought than I've put in just now).

> I'd prefer to say that C is a single language whose semantics
> are not entirely specified in all cases. Saying that it has
> "non-deterministic semantics" could imply that each implementation
> is required to behave in a non-deterministic manner, which of course
> it isn't.

It does behave in a non-deterministic manner in the literal sense
of non-deterministic, that is, it is not determined by the
definition. An implementation that bases its choices on random
events that by chance always happens to take the first choice is
still "non-deterministic"; so is an implementation that simply
decided always to take the first choice available. However you
are right that it is potentially confusing, so to be explicit
and also (hopefully) clear, I will say that by "non-deterministic
semantics" I mean that an implementation may elect any choice
resolution mechanism it wishes, including both mechanisms that
are completely regular and predictable and also mechanisms that
make totally unpredictable choices, or any combination of
predictable, unpredictable, and/or "random".

== 2 of 6 ==
Date: Sat, Apr 10 2010 12:40 pm
From: Keith Thompson

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On 10 Apr, 19:07, Keith Thompson <ks...@mib.org> wrote:
>> I'll concede that some people refer to a function's return type
>> as the type of the function, and this can be fairly harmless in
>> informal discussions.  But such usage is strictly incorrect, and
>> either using it in a C reference book or attempting to "correct"
>> someone who has used the terms correctly is just wrong.
>>
> "type" is a C technical term. The problem is that we can't restrict
> the word to this usage, even when discussing the C standard, because
> it is too common an English word.

I disagree. When we're discussing the C standard we most certainly
*can* (and should) use the word "type" with the meaning defined by the
C standard. What's the point of having the standard define meanings
for terms if we're unwilling or unable to use them that way?

And what exactly is the common English meaning of "type" for which a
function can have type int?

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

== 3 of 6 ==
Date: Sat, Apr 10 2010 12:44 pm
From: Malcolm McLean

On 10 Apr, 20:40, Keith Thompson <ks...@mib.org> wrote:
> Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>
> And what exactly is the common English meaning of "type" for which a
> function can have type int?
>
The "type" of a "function" in non-C terms would be "real" or
"integral", as well as other characteristics like "monotonic" or
"differentiable".

== 4 of 6 ==
Date: Sat, Apr 10 2010 1:04 pm
From: Willem

Malcolm McLean wrote:
) On 10 Apr, 20:40, Keith Thompson <ks...@mib.org> wrote:
)> Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
)>
)> And what exactly is the common English meaning of "type" for which a
)> function can have type int?
)>
) The "type" of a "function" in non-C terms would be "real" or
) "integral", as well as other characteristics like "monotonic" or
) "differentiable".

Those are definitions from mathematics. I would hardly call that
'common English'. In common English, I expect things like
"has side effects", "works with filehandles" or "takes a long time".

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

== 5 of 6 ==
Date: Sat, Apr 10 2010 1:19 pm
From: Richard Heathfield

spinoza1111 wrote:
> On Apr 8, 12:52 am, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2010-04-07, James Harris <james.harri...@googlemail.com> wrote:
>>
>>> Judging by the faults Richard is finding and, most importantly, Edward
>>> is neither challenging nor refuting, it's beginning to look like an
>>> updated CTCN would be as long as the book it is criticising!
>> I would guess longer. The error density, when things go wrong, is AMAZING.
>
> Richard and Seebach are in desp[e]ration mode.

Not really. Oh, and IFYPFY.

> Omission of obviously
> needed variables in a code example is NOT AN ERROR.

Yes, it is.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 6 of 6 ==
Date: Sat, Apr 10 2010 1:23 pm
From: Richard Heathfield

spinoza1111 wrote:
<snip>

>
> If Seebach wishes to immortalize his incompetence and malice, the
> clearest way would be to create a wikipedia article on this affair,
> describing how a small number of the more intelligent posters on clc
> got him to retract. That should be interesting.

He has nothing to retract. CTCN is insufficiently critical of CTCR, and
some of the criticisms could have been better worded, but none of the
criticisms has been shown to be inaccurate. Since he hasn't retracted, a
Wikipedia article describing a retraction would be inaccurate right from
the start. As for the more intelligent posters on clc, none of them has
so far suggested that he retract anything.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

==============================================================================
TOPIC: Question about void
http://groups.google.com/group/comp.lang.c/t/7cda9a8237a38531?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Apr 10 2010 12:04 pm
From: James Kanze

On Apr 10, 1:00 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> sandeep <nos...@nospam.com> writes:
> >WHY we cannot have a void variable?

> In C, »void« is an incomplete type and, therefore, lacks
> information needed to determine the size of x.

> I do not recommend crossposting such a question to both
> comp.lang.c and comp.lang.c++: Because they are separate
> languages, this should be discussed separately. Therefore,
> I did not answer for C++, but only for C above.

Except that in this particular case, C and C++ are identical.
In general, C++ tries to be compatible with C when it is a
question of only the basic types (or composite types which it
has in common with C). Thus, any differences in the definition
of int in C and in C++ can be considered bugs in the C++
standard.

And void, of course, is a basic type in C, and thus in C++.

--
James Kanze

== 2 of 2 ==
Date: Sat, Apr 10 2010 12:18 pm
From: "Alf P. Steinbach"

* James Kanze:
> On Apr 10, 1:00 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>> sandeep <nos...@nospam.com> writes:
>>> WHY we cannot have a void variable?
>
>> In C, »void« is an incomplete type and, therefore, lacks
>> information needed to determine the size of x.
>
>> I do not recommend crossposting such a question to both
>> comp.lang.c and comp.lang.c++: Because they are separate
>> languages, this should be discussed separately. Therefore,
>> I did not answer for C++, but only for C above.
>
> Except that in this particular case, C and C++ are identical.

Not at all.

Look else-thread and you'll find a lot of C-specific discussion, and a lot of
C++-specific discussion.

> In general, C++ tries to be compatible with C when it is a
> question of only the basic types (or composite types which it
> has in common with C). Thus, any differences in the definition
> of int in C and in C++ can be considered bugs in the C++
> standard.

'int'?

Anyway, although your point is irrelevant to the present discussion (see below),
it's not the case that C++ fundamental types that have corresponding types in C
are equivalent to those C types. In particular the languages differ, as I
recall, in allowing/disallowing padding bits and trap representations for
fundamental types.

> And void, of course, is a basic type in C, and thus in C++.

Consider 'char&' in C++. This is one thing you can do with 'char' in C++ that
you cannot do with it in C. Your argument that things that cannot be done in C
shouldn't be allowed in C++ is not meaningful.

Not that I support of the notion of 'void' variables (see else-thread).

But this particular argument against it is not sound.

Cheers & hth.,

- Alf

==============================================================================
TOPIC: seebs/schildt I
http://groups.google.com/group/comp.lang.c/t/9f0200c489f848f8?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Apr 10 2010 12:11 pm
From: Seebs

On 2010-04-10, Richard Harter <cri@tiac.net> wrote:
> On 10 Apr 2010 17:28:15 GMT, Seebs <usenet-nospam@seebs.net>
> wrote:
>>Not even that. One of the reasons people in general get along with me
>>is that I'm actually pretty funny. Often intentionally!

> I must say that your posts are often quite witty. :-)

Is this like "I must say that I had a wonderful time"?

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 2 of 2 ==
Date: Sat, Apr 10 2010 12:28 pm
From: cri@tiac.net (Richard Harter)

On 10 Apr 2010 19:11:39 GMT, Seebs <usenet-nospam@seebs.net>
wrote:

>On 2010-04-10, Richard Harter <cri@tiac.net> wrote:
>> On 10 Apr 2010 17:28:15 GMT, Seebs <usenet-nospam@seebs.net>
>> wrote:
>>>Not even that. One of the reasons people in general get along with me
>>>is that I'm actually pretty funny. Often intentionally!
>
>> I must say that your posts are often quite witty. :-)
>
>Is this like "I must say that I had a wonderful time"?

Not at all. The words are the same but the meanings are
different.

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.

==============================================================================
TOPIC: Test of a preprocessor symbol defined as nothing vs. zero
http://groups.google.com/group/comp.lang.c/t/8e4236bf3f19c661?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Apr 10 2010 12:31 pm
From: Mark Adler

Outside of my source file, someone will do one of these four things:

A. #undef FOO

or

B. #define FOO

or

C. #define FOO 0

or

D. #define FOO 1

I need to consider A and C to be equivalent, and B and D to be
equivalent. How do I test for that?

Some example tests:

#if FOO is true for D. #ifdef FOO is true for B, C, and D. #if FOO+0
== 0 is true for B and C.

The problem is that I can't find a test that distinguishes cases B and C.

Any suggestions?

Mark

== 2 of 3 ==
Date: Sat, Apr 10 2010 12:52 pm
From: Malcolm McLean

On 10 Apr, 20:31, Mark Adler <mad...@alumni.caltech.edu> wrote:
> Outside of my source file, someone will do one of these four things:
>
> A.  #undef FOO
>
> or
>
> B.  #define FOO
>
> or
>
> C.  #define FOO 0
>
> or
>
> D.  #define FOO 1
>
> I need to consider A and C to be equivalent, and B and D to be
> equivalent.  How do I test for that?
>
> Some example tests:
>
> #if FOO is true for D.  #ifdef FOO is true for B, C, and D.  #if FOO+0
> == 0 is true for B and C.
>
> The problem is that I can't find a test that distinguishes cases B and C.
>
> Any suggestions?
>
> Mark

#ifdef FOO
#if FOO != 0
#undef FOO
#define FOO 1