🚀 go-pugleaf

> From: Rune.huseby@gpi.telemax.no (Rune Huseby)
> 
> In Visual C++ 1.5 and Borland C++, the following example prints "false",
even 
> though section 6.2.2.3 of the standard gives that it should print "true"
> 
> void main(void)
> {
>   int *ptr1 = NULL;
>   int __far *ptr2 = NULL;
>   
>   if(ptr1 == ptr2)
>      printf("true");
>   else
>      printf("false");     
> }
> 
> (FYI, the __far keyword tells the compiler to store the segment and
offset in 
> the variable, while the other only stores the offset, and uses the
default 
> data segment)

In subclause 6.2.2.3:

	Two null pointers, converted thought possibly different sequences
	of casts to pointer types, shall compare equal.

At first glance, this would appear to be a bug in the compiler.  Here's
why we might think so:

	/*
	 * Think of some machine that uses different formats
	 * for byte and word pointers, e.g., PDP-10.
	 */
	char *ptr3; /* native byte-format pointer */
	int *ptr4; /* native word-format pointer */

In this example, the "char" pointer is twice the size of the
"int" pointer, and assigning an "int" pointer to the "char" pointer
causes additional information to be inserted (i.e., this is like your
example).  When comparing a "char" null pointer to an "int" null pointer
in Standard C, they must compare equal.

So why doesn't your example work?  Part of the problem is that "__far"
isn't part of ANSI C.  (BTW, there was some work in X3J11.1 on distributed
objects, similar to "near", "far", and "huge", except it was for massively
parallel machines.  I have a proposal for this in C9X, but I haven't
presented in yet.  See the directory "c9x/Tabled" in the FTP site.)  When
a vendor extends the language, they are free to add whatever they want
(unfortunately) without regard to existing practice, i.e., they can
break anything.  A simple, but understandable, breakage would be the
axiom that "void *" is no longer the widest pointer.  In fact it might be
"void __far *" (or even "void __far32 *" on some systems).  This makes
sense on these systems.  The vendors are free to violate the rule ``two
null pointers shall compare the same'' when using pointers outside of
Standard C types.  However, subclause 6.3.9 makes it clear how to get
this right:

	== Operator:

	...
	If two pointers to object or imcomplete types are both null
	pointers, they compare equal.  If two pointers to object or
	incomplete types compare equal, they are null pointers, or
	both point to the same object, or both point one past the last
	element of the same array object.

Unfortunately, vendors don't have to get this right in their extensions.
You might make a case to the vendor that the *expected* behavior is
to get null pointers to match.  They'll probably gripe about the
performance hit.  Anyway, the following should always work:

	if ( ptr1 == ptr2 || ( ptr1 == NULL && ptr2 == NULL ) )

assuming they haven't broken testing against "NULL" :-).

-FF
-------------------------------------------------------------------
(``I only use AOL for reading netnews.'')
Frank Farance, Farance Inc.
E-mail: frank@farance.com, Telephone: +1 212 486 4700
ISO JTC1/SC22/WG14 & ANSI X3J11 (C Programming Language) Project Editor