Programming Puzzle

[Jatinder]

I found these questions on a web site and wish to share with all of u
out there,Can SomeOne Solve these Porgramming puzzles.
Programming Puzzles

Some companies certainly ask for these things. Specially Microsoft.
Here are my favorite puzzles. Don't send me emails asking for the
solutions.

Q1 Write a "Hello World" program in 'C' without using a semicolon.
Q2 Write a C++ program without using any loop (if, for, while etc) to
print numbers from 1 to 100 and 100 to 1;
Q3 C/C++ : Exchange two numbers without using a temporary variable.
Q4 C/C++ : Find if the given number is a power of 2.
Q5 C/C++ : Multiply x by 7 without using multiplication (*) operator.
Q6 C/C++ : Write a function in different ways that will return f(7) =
4 and f(4) = 7
Q7 Remove duplicates in array
Q8 Finding if there is any loop inside linked list.
Q9 Remove duplicates in an no key access database without using an
array
Q10 Write a program whose printed output is an exact copy of the
source. Needless to say, merely echoing the actual source file is not
allowed.
Q11 From a 'pool' of numbers (four '1's, four '2's .... four '6's),
each player selects a number and adds it to the total. Once a number
is used, it must be removed from the pool. The winner is the person
whose number makes the total equal 31 exactly.
Q12 Swap two numbers without using a third variable.
Given an array (group) of numbers write all the possible sub groups of
this group.
Q14 Convert (integer) number in binary without loops.

Q3,12 are similar , Q7 is simple & I know there answer For the Rest
please Help
Wiating for reply.

[Dan Pop]

In <YX*******************@newssvr27.news.prodigy.co m> "Mabden" <mabden@sbc_global.net> writes:

"Michael" <mi************@excite.com> wrote in message
news:20**************************@posting.google. com...

> Please describe (in code) a situation where two variables share the samememory > location.
>

Dan you need to try stuff for yourself

Oohhhh.. you're arguing with Dan....

Nope, he isn't, but you're way too stupid to realise that. Clue: he was
replying to a request made by Julie and incorrectly mentioning my name.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Alex Monjushko]

In comp.lang.c Julie <ju***@nospam.com> wrote:

Michael wrote:

> Please describe (in code) a situation where two variables share the same memory
> location.
> Dan you need to try stuff for yourself

#include <stdio.h>

int main(void){
int x=10, *p;
p=&x;
printf("%p, %p\n",(void *)p,(void *)&x);
return 0;
}

You need to think a little harder: You have two variables: x and p. Are you saying that &x == &p? I sure hope
not.

That is not what he is saying. You are failing to grasp that *p is a
variable. Perhaps this quote from page 45 of K&R2 will enlighten you:

"...The increment and decrement operators can only be applied
to variables..."

This, in my mind, would mean that *p can be considered a variable, at
least part of the time. Technically, of course, *p can hardly be
considered a variable when p does not contain the address of a valid
object.

--
Alex Monjushko (mo*******@hotmail.com)

[Herb Sutter]

I haven't read this thread, but:

You have two variables: x and p. Are you saying that &x == &p? I sure hope
not.

Of course, you can easily construct that sort of aliasing:

int a, &b = a;
assert( &a == &b );

I suspect the point of the thread was something else.

Also, FWIW, optimizers routinely fold objects like a and b below (i.e.,
they can occupy the same memory address) because the optimizer can prove
that a conforming program can't tell because their uses don't overlap:

#include <stdio.h>

int main() {
int a = 10;
printf( "%d", a );
int b = 20;
printf( "%d", b );
}

Herb

---
Herb Sutter (www.gotw.ca)

Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
Visual C++ architect, Microsoft (www.gotw.ca/microsoft)

[Keith Thompson]

Herb Sutter <hs*****@gotw.ca> writes:
[...]

Also, FWIW, optimizers routinely fold objects like a and b below (i.e.,
they can occupy the same memory address) because the optimizer can prove
that a conforming program can't tell because their uses don't overlap:

#include <stdio.h>

int main() {
int a = 10;
printf( "%d", a );
int b = 20;
printf( "%d", b );
}

To expand on that point a bit, an optimizer can fold a and b because
it can prove that *this particular* program can't tell the difference
(and it's allowed to assume, for purposes of its proof, that the
program doesn't exhibit undefined behavior).

A conforming program could compare the addresses of a and b and expect
them to be different, but that would be a different program, and one
in which the optimizer wouldn't be allowed to fold a and b.

Actually, I'm making an assumption that I'm not 100% certain is
correct. Can a conforming implementation fold a and b if their uses
don't overlap, but the program examines their addresses? In other
words, the following program:

#include <stdio.h>
int main(void)
{
int a, b;

a = 10;
printf("a = %d, ", a);

b = 20;
printf("b = %d, ", b);

printf("addresses are %s\n", &a == &b ? "equal" : "unequal");

return 0;
}

should normally print

a = 10, b = 20, addresses are unequal

if a and b are not folded. If it prints

a = 10, b = 20, addresses are equal

does it imply that the compiler is non-conforming?

This is cross-posted to comp.lang.c and comp.lang.c++. If you're
going to reply based on either language standard, please follow up to
the appropriate group.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ioannis Vranos]

Keith Thompson wrote:

[...]

Fellows we got in the same stuff again. Actually the wrong side of the
subject has been erased. At first cross-posting in clc++ and clc has
nothing useful to provide. They are separate languages. Regarding C++ as
I had said in some messages earlier in the thread:

The C++ standard says:

"A variable is introduced by the declaration of an object. The
variable’s name denotes the object."

"An object is a region of storage. [Note: A function is not an object,
regardless of whether or not it occupies storage in the way that objects
do. ] An object is created by a definition (3.1), by a new-expression
(5.3.4) or by the implementation (12.2) when needed."
So in terminology, a variable can only denote one object, which is
always different from another object.
The original question becomes "what if we pass the same object to the
swap function?".
If you do not use the correct terminology, you will never reach a
conclusion, since both of you use your own terminologies.
----

A pointer is a variable that denotes an object (which stores addresses).

A dereferenced pointer is not a variable (since it is not introduced by
the declaration of an object), but represents an object.
As I said, the original question becomes: "what if we pass the same
object to the swap function?".

It would be nice if you tried to communicate on this basis.


Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

[Chris Torek]

In article <ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> writes:

... Can a conforming implementation fold a and b if their uses
don't overlap, but the program examines their addresses? In other
words, the following program:

#include <stdio.h>
int main(void)
{
int a, b;

a = 10;
printf("a = %d, ", a);

b = 20;
printf("b = %d, ", b);

printf("addresses are %s\n", &a == &b ? "equal" : "unequal");

return 0;
}

should normally print

a = 10, b = 20, addresses are unequal

if a and b are not folded. If it prints

a = 10, b = 20, addresses are equal

does it imply that the compiler is non-conforming?

In C at least, yes it does. (I would be quite surprised if the
answer changes for C++.) Note that the compiler *can* still combine
the underlying storage space for "a" and "b", as long as it *also*
pretends that &a != &b even though then &a == &b. For instance,
suppose the compiler first tries to optimize the printf() call.
At this time, "a" and "b" are still separate entities in the
compiler's internal representation (e.g., separate RTL pseudo-registers
inside GCC). Thus the result of &a==&b is a known constant 0 (in
C). The next step is to replace:

printf("addresses are %s\n", 0 ? "equal" : "unequal");

with:

printf("addresses are %s\n", "unequal");

and perhaps even optimize this into:

puts("addresses are unequal"); /* note, puts() adds the \n */

Now that this has been done, there is no longer any occurrence of
&a or &b, so now the entities "a" and "b" can be folded together
to occupy the same hard-register-or-stack-slot. So now &a==&b even
though the code that prints whether &a==&b says they are not!
(Of course, if they are in a "hard register" they may not have an
address at all; and in the case of GCC, at least, constant propagation
would result in their removal entirely, at this point.)

If you were to replace the above printf() call with:

printf("addresses are %p and %p\n", (void *)&a, (void *)&b);

the system would have to print two different numbers, in general,
and this would probably preclude the sort of folding described
here.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Keith Thompson]

Chris Torek <no****@torek.net> writes:

In article <ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> writes:

... Can a conforming implementation fold a and b if their uses
don't overlap, but the program examines their addresses? In other
words, the following program:

#include <stdio.h>
int main(void)
{
int a, b;

a = 10;
printf("a = %d, ", a);

b = 20;
printf("b = %d, ", b);

printf("addresses are %s\n", &a == &b ? "equal" : "unequal");

return 0;
}

should normally print

a = 10, b = 20, addresses are unequal

if a and b are not folded. If it prints

a = 10, b = 20, addresses are equal

does it imply that the compiler is non-conforming?

In C at least, yes it does. (I would be quite surprised if the
answer changes for C++.)

I believe you, but how does the standard imply this?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Julie]

Ioannis Vranos wrote:

Keith Thompson wrote:

> [...]
Fellows we got in the same stuff again. Actually the wrong side of the
subject has been erased. At first cross-posting in clc++ and clc has
nothing useful to provide. They are separate languages. Regarding C++ as
I had said in some messages earlier in the thread:

The C++ standard says:

Fortunately, comp.lang.c* doesn't have to restrict itself to just specifically
what is contained/defined within the standard. Such limited discussions are
appropriate in comp.std.c*; here we can talk about the language, as defined by
the standard.
"A variable is introduced by the declaration of an object. The
variable’s name denotes the object."
Fine -- but what that is saying is that when you create an object, you also
introduce a variable. The opposite is not necessarily true: introducing a
variable does *NOT* imply the declaration of an object.

If that is the extent of what is discussed in the standard, then the short of
it is that the standard does not define what a variable is.
"An object is a region of storage. [Note: A function is not an object,
regardless of whether or not it occupies storage in the way that objects
do. ] An object is created by a definition (3.1), by a new-expression
(5.3.4) or by the implementation (12.2) when needed."

Seems like it isn't complete to me. Either the other ways (C-style?) to
instanciate an 'object' are either implied or just plain left out. Consider
the differences between:

int i; // created by a definition

int * j = new int; // by a new-expression

extern int k; // by the implementation

int * l = (int *)malloc(sizeof(int)); // what about me?

[Ioannis Vranos]

Julie wrote:

"A variable is introduced by the declaration of an object. The
variable’s name denotes the object."

Fine -- but what that is saying is that when you create an object, you also
introduce a variable. The opposite is not necessarily true: introducing a
variable does *NOT* imply the declaration of an object.

No it says that you declare an object by using a variable. So when you
"declare" a variable in essence you declare an object.
If that is the extent of what is discussed in the standard, then the short of
it is that the standard does not define what a variable is.
It does. A variable (its name) denotes an object.

"An object is a region of storage. [Note: A function is not an object,
regardless of whether or not it occupies storage in the way that objects
do. ] An object is created by a definition (3.1), by a new-expression
(5.3.4) or by the implementation (12.2) when needed."

Seems like it isn't complete to me. Either the other ways (C-style?) to
instanciate an 'object' are either implied or just plain left out. Consider
the differences between:

int i; // created by a definition

int * j = new int; // by a new-expression

extern int k; // by the implementation

Actually defined in another compilation unit.
int * l = (int *)malloc(sizeof(int)); // what about me?

In the above cases we have:

int i;

i is a variable that denotes an object.
int *j=new int;
j is a variable that denotes an int * object, that is the pointer itself.

The new int that is created in the free store is another object, not
denoted by a variable, since it is not created by a variable declaration.

extern int k; means that it is defined elsewhere (in general) and the
"int i" case applies for the definition.
The malloc() situation is the same with the new int situation.


Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

[Alex Monjushko]

In comp.lang.c Ioannis Vranos <iv*@guesswh.at.grad.com> wrote:

Julie wrote:

extern int k; // by the implementation

Actually defined in another compilation unit.

Not necessarily. Consider the following, in the same translation unit.

static int a = 42;

extern int a; /* deceptive use of 'extern' */

--
Alex Monjushko (mo*******@hotmail.com)

[Ioannis Vranos]

Alex Monjushko wrote:

Not necessarily. Consider the following, in the same translation unit.

static int a = 42;

extern int a; /* deceptive use of 'extern' */

As I had said for this one later in the message:

"extern int k; means that it is defined elsewhere (in general)"


Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

[Alex Monjushko]

In comp.lang.c Ioannis Vranos <iv*@guesswh.at.grad.com> wrote:

Alex Monjushko wrote:

Not necessarily. Consider the following, in the same translation unit.

static int a = 42;

extern int a; /* deceptive use of 'extern' */

As I had said for this one later in the message: "extern int k; means that it is defined elsewhere (in general)"

"Elsewhere" is technically correct, but it is a little vague in light
of your initial reference to separate translation units.

--
Alex Monjushko (mo*******@hotmail.com)

[Ioannis Vranos]

Alex Monjushko wrote:

In comp.lang.c Ioannis Vranos <iv*@guesswh.at.grad.com> wrote:

Alex Monjushko wrote:

Not necessarily. Consider the following, in the same translation unit.

static int a = 42;

extern int a; /* deceptive use of 'extern' */

As I had said for this one later in the message:

"extern int k; means that it is defined elsewhere (in general)"

"Elsewhere" is technically correct, but it is a little vague in light
of your initial reference to separate translation units.

Ok, OK! :-)


Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

[Julie]

Keith Thompson wrote:

This is posted only to comp.lang.c++, which I don't regularly follow.

Julie <ju***@nospam.com> writes:

Ioannis Vranos wrote: [...]

The C++ standard says: [...] "A variable is introduced by the declaration of an object. The
variable's name denotes the object."

Fine -- but what that is saying is that when you create an object, you also
introduce a variable. The opposite is not necessarily true: introducing a
variable does *NOT* imply the declaration of an object.

The first occurence of "variable" in the above quotation from the
standard is in italics. That means it's the definition of the word
"variable", which implies that it's exclusive, i.e., that anything not
introduced by the declaration of an object is not a variable.

You may want to research predicate logic.
That may or may not match the common usage of the term, but if that's
what the standard says it seems appropriate to stick to that
definition.

(The C standard, on the other hand, doesn't define the word
"variable", which is why I dropped comp.lang.c from the Newsgroups
header.)

Again, this discussion doesn't have to limit itself to what is or is not
included in any standard. This discussion is about languages, in a forum about
languages (comp.lang.c*), as defined about standards. Variable discussions in
comp.std.c may be inappropriate, here in comp.lang.c, it is perfectly
appropriate -- I've re-added the newsgroup to this reply.

[Ioannis Vranos]

Ioannis Vranos wrote:

Alex Monjushko wrote:

In comp.lang.c Ioannis Vranos <iv*@guesswh.at.grad.com> wrote:

Alex Monjushko wrote:

Not necessarily. Consider the following, in the same translation unit.

static int a = 42;
extern int a; /* deceptive use of 'extern' */

As I had said for this one later in the message:

"extern int k; means that it is defined elsewhere (in general)"

"Elsewhere" is technically correct, but it is a little vague in light
of your initial reference to separate translation units.

Ok, OK! :-)

Also extern int k; can be a definition by itself in the absence of any
other definition.


Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Julie wrote:

Again, this discussion doesn't have to limit itself to what is or is not
included in any standard. This discussion is about languages, in a forum about
languages (comp.lang.c*), as defined about standards. Variable discussions in
comp.std.c may be inappropriate, here in comp.lang.c, it is perfectly
appropriate -- I've re-added the newsgroup to this reply.

Yes it is about the language as defined by the standard, so we should be
better stick to the terminology of the standard, if for not other reason
to be able to understand one another.

clc on the other hand is another language so by adding other languages
newsgroups can only add more confusion.


Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Ioannis Vranos wrote:

Yes it is about the language as defined by the standard, so we should be
better stick to the terminology of the standard, if for not other reason
to be able to understand one another.

clc on the other hand is another language

newsgroup

so by adding other languages
newsgroups can only add more confusion.

Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

[Julie]

Ioannis Vranos wrote:

Julie wrote:

"A variable is introduced by the declaration of an object. The
variable’s name denotes the object."

Fine -- but what that is saying is that when you create an object, you also
introduce a variable. The opposite is not necessarily true: introducing a
variable does *NOT* imply the declaration of an object.

No it says that you declare an object by using a variable. So when you
"declare" a variable in essence you declare an object.

It doesn't say that or infer that at all. Research predicate logic. You can't
assume the reverse of an inference is true.

Specifically:

'declaration of an object' implies 'variable is introduced' (always true)

cannot be reversed to:

'variable is introduced' implies 'declaration of an object' (conditionally
true)

If that is the extent of what is discussed in the standard, then the short of
it is that the standard does not define what a variable is.

It does. A variable (its name) denotes an object.

"An object is a region of storage. [Note: A function is not an object,
regardless of whether or not it occupies storage in the way that objects
do. ] An object is created by a definition (3.1), by a new-expression
(5.3.4) or by the implementation (12.2) when needed."

Seems like it isn't complete to me. Either the other ways (C-style?) to
instanciate an 'object' are either implied or just plain left out. Consider
the differences between:

int i; // created by a definition

int * j = new int; // by a new-expression

extern int k; // by the implementation

Actually defined in another compilation unit.

So what? I was giving an example of the something 'created ... by the
implementation', presuming that k is part of the implementation.

int * l = (int *)malloc(sizeof(int)); // what about me?

In the above cases we have:

int i;

i is a variable that denotes an object.

int *j=new int;

j is a variable that denotes an int * object, that is the pointer itself.

The new int that is created in the free store is another object, not
denoted by a variable, since it is not created by a variable declaration.

extern int k; means that it is defined elsewhere (in general) and the
"int i" case applies for the definition.

The malloc() situation is the same with the new int situation.

Not the same, but similar, and *not* included in the standard text that you
quoted. That was my point -- the standard text is incomplete, or your
quote/reference is.

[Ioannis Vranos]

Julie wrote:

It doesn't say that or infer that at all. Research predicate logic. You can't
assume the reverse of an inference is true.

Specifically:

'declaration of an object' implies 'variable is introduced' (always true)

cannot be reversed to:

'variable is introduced' implies 'declaration of an object' (conditionally
true)

Ok. You may continue wasting your energy in endless discussions. :-)

The malloc() situation is the same with the new int situation.

Not the same, but similar, and *not* included in the standard text that you
quoted. That was my point -- the standard text is incomplete, or your
quote/reference is.

What do you mean not included. It is the same case with operator new.


Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

[Julie]

Ioannis Vranos wrote:

Julie wrote:

It doesn't say that or infer that at all. Research predicate logic. You can't
assume the reverse of an inference is true.

Specifically:

'declaration of an object' implies 'variable is introduced' (always true)

cannot be reversed to:

'variable is introduced' implies 'declaration of an object' (conditionally
true)

Ok. You may continue wasting your energy in endless discussions. :-)

I'm getting close to being out of energy on this discussion...

[Chris Torek]

>> In article <ln************@nuthaus.mib.org>

Keith Thompson <ks***@mib.org> writes: [snippage -- but "a" and "b" are distinct objects of type "int"]

printf("addresses are %s\n", &a == &b ? "equal" : "unequal");
... If [this] prints
a = 10, b = 20, addresses are equal
does it imply that the compiler is non-conforming?

Chris Torek <no****@torek.net> writes:

In C at least, yes it does. (I would be quite surprised if the
answer changes for C++.)

In article <news:ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> writes:I believe you, but how does the standard imply this?

The most important item is the description of the "!=" operator.
This is from a C99 draft, but the key wording is unchanged from
C89:

6.3.9 Equality operators
...
Semantics
...
[#4] If two pointers to object or incomplete types are both
null pointers, they compare equal. If two pointers to
object or incomplete types compare equal, they both are null
pointers, or both point to the same object, or both point
one past the last element of the same array object.79 ...

One also must look at the unary-& operator, of course; but if &a == &b,
the two pointers involved are:

- both NULL (better not be), or

- both point to the same object (better not; "a" and "b" are not
the same object, even if they occupy the same physical location
*after* optimization), or

- both point one past the last element of the same array object.

Since none of these is true, the result of the "==" and "!="
operators must be "not equal".

I think the stickiest point here really lies in figuring out what
defines a "unique" or "distinct" object. Other than via unions,
or nonportable assembly tricks like __asm__(".global a, b; b = a"),
objects with different "ordinary variable names" must be distinct,
although the inverse is not true (same-name can still be distinct):

int a, b, c; /* a, b, and c are all distinct */
void f(void) {
int a;
extern int b;
static char *c;
/* f()'s a and c are not the same as the file-scope a and c,
while f()'s b is the same as the file-scope b. */
...
}

Unions make a mockery of distinctness:

union {
char a;
float b;
long double complex c; /* c99 only */
} u;

Here u.a, u.b, and u.c are not actually distinct objects, although
sizeof(u.a) is 1, and probably sizeof(u.b) is greater than 1
(typically 4) while sizeof(u.c) is probably greater still (typically
16, 24, or 32 today), so that "most of" u.c is probably distinct
from u.a, in a way.

One can also make a mess with macros, but in general, if you see
C code that refers to "i" and then "j", these will be distinct
objects. Even more complicated names/expressions like s.x and s.y
or p->x and p->y *probably* refer to distinct objects.

The rules for whether identical ordinary identifiers refer to the
same underlying object *are* spelled out (in great detail) in the
Standard, but this requires going through the sections on scope
and linkage. Note that there are cases where "logically distinct"
objects *are* allowed to share underlying memory, but the only
way to test it is to invoke undefined behavior:

void f(void) {
int *p;
{
int i;
p = &i;
}
/* BEWARE: the value in p is now "indeterminate" */
{
int j;
printf("i (which no longer exists) and j do%s occupy "
"the same space\n", (p == &j) ? "" : " not");
/* ERROR -- use of the indeterminate value in p produces
undefined behavior */
}
}

This function will generally compile and run (perhaps with a warning
from a particularly clever compiler) but produces undefined behavior,
so one cannot prove anything from it. Your (Keith's) original
example *does* have defined behavior, and must claim that the
addresses are unequal.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Keith Thompson]

Chris Torek <no****@torek.net> writes:

In article <ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> writes: [snippage -- but "a" and "b" are distinct objects of type "int"] printf("addresses are %s\n", &a == &b ? "equal" : "unequal");
... If [this] prints
a = 10, b = 20, addresses are equal
does it imply that the compiler is non-conforming?

Chris Torek <no****@torek.net> writes:

In C at least, yes it does. (I would be quite surprised if the
answer changes for C++.)

In article <news:ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> writes:

I believe you, but how does the standard imply this?

The most important item is the description of the "!=" operator.
This is from a C99 draft, but the key wording is unchanged from
C89:

6.3.9 Equality operators
...
Semantics
...
[#4] If two pointers to object or incomplete types are both
null pointers, they compare equal. If two pointers to
object or incomplete types compare equal, they both are null
pointers, or both point to the same object, or both point
one past the last element of the same array object.79 ...

[snip]

Yes, that does it. Thanks.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.