From xemacs-m  Sat Jun 21 14:31:51 1997
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by xemacs.org (8.8.5/8.8.5) with SMTP id OAA20132
	for <xemacs-beta@xemacs.org>; Sat, 21 Jun 1997 14:31:51 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA25440 for <xemacs-beta@xemacs.org>; Sat, 21 Jun 1997 12:53:49 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id MAA06176; Sat, 21 Jun 1997 12:31:20 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA27854; Sat, 21 Jun 1997 12:31:19 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA08312; Sat, 21 Jun 1997 12:31:19 -0700
Date: Sat, 21 Jun 1997 12:31:19 -0700
Message-Id: <199706211931.MAA08312@xemacs.eng.sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Hrvoje Niksic <hniksic@srce.hr>
Cc: XEmacs Developers <xemacs-beta@xemacs.org>
Subject: Re: Yet more 64bits lossage
In-Reply-To: <kigu3irrcq1.fsf@jagor.srce.hr>
References: <19970621012424.18989@iria.mines.u-nancy.fr>
	<199706210604.XAA07502@xemacs.eng.sun.com>
	<19970621082753.50969@iria.mines.u-nancy.fr>
	<kiglo445ua5.fsf@jagor.srce.hr>
	<199706211901.MAA08300@xemacs.eng.sun.com>
	<kigu3irrcq1.fsf@jagor.srce.hr>
X-Mailer: VM 6.32 under 20.3 "Oslo" XEmacs Lucid (beta7)
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>

>>>>> "Hrv" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrv> Martin Buchholz <mrb@Eng.Sun.COM> writes:
>> A definition of NULL as 0 is sufficient if application writers always
>> cast NULL to pointer in an ambiguous context like varargs argument
>> lists.  Almost everyone is guilty of getting this wrong, including us
>> and the O'Reilly manuals (read the docs for XtVaSetValues).  The X
>> docs assume that using NULL is good enough.

Hrv> The X docs are wrong.  Anyway, that is solved by using

Hrv> #define NULL (void *)0

>> 1. sizeof(NULL) == sizeof(void *), so the natural (albeit buggy) code

Hrv> OK.

>> 3. The code
>> 
>> int foo(char*);
>> foo(NULL);
>> 
>> compiles cleanly under C *and* C++.
>> (This is why
>> #define NULL ((void *)0)
>> doesn't work.)

Hrv> That is C++.  I was talking about ANSI C.  Anyway, it is not clear to
Hrv> me why your one can pass (long)0 to a function expecting char*, but
Hrv> not (void*)0.  I guess some things about C++ are better left
Hrv> unanswered.  It might be instantaneously replaced by something even
Hrv> more complex and less logical.  Some say it already happened.

Passing 0 or 0L to a C function is always identical, unless the type
of the argument is not available, such as an unprototyped function or
a varargs function like printf.

When the C compiler builds the argument list for

printf("%p", 0);

it doesn't know that printf will extract a pointer's worth of bytes
from the stack.  The only information it has is "0", so it provides an
int's worth of bytes.  So printf will read more bytes from the stack
than is provided by the caller (if sizeof(void*) > sizeof(int)),
leading to the usual C catastrophe.

Because it is much more likely to be true that
sizeof(long) == sizeof(void*)
than
sizeof(int) == sizeof(void*)

0L is a better definition for NULL than 0.


>> works on almost every system, and is a better definition for NULL.
>> In particular, it's a better definition on Irix 64.

Hrv> Yup.

>> This kind of stuff is really tricky to get right.

Hrv> It depends on the audience you target.  In ANSI C, `#define NULL 0' is 
Hrv> as "right" as you can get.

If all you care about is ANSI C, `#define NULL ((void*)0)' is as
"right" as you can get.  If you want to have a definition that also
works with C++, then `#define NULL 0L' is as right as you can get.

Perhaps the best definition is

#ifdef __cplusplus
#define NULL 0L
#else
#define NULL ((void*)0)
#endif

Martin

