Date: Sat, 29 Nov 2003 16:39:14 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: standards@freebsd.org Subject: Re: 64-bit NULL: a followup Message-ID: <20031129161509.J4841@gamplex.bde.org> In-Reply-To: <20031129005823.GA20090@dhcp01.pn.xcllnt.net> References: <20031129005823.GA20090@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 28 Nov 2003, Marcel Moolenaar wrote:
> Notice the "st8". Since NULL is a pointer constant, programmers do
> (implicitly) expect it to have the same width as a pointer type and
> thus do not cast it to a pointer type or an integer type that has a
> width larger or equal to a pointer type.
FreeBSD programmers would never do that ;-), since style(9) requires
casting of NULL in function args and mentions this point. (This part
of style(9) was written before everything in FreeBSD was prototyped,
so the cast was required even for non-variadic functions.)
> So, the bottomline is that we currently do have third-party code that
> fails to run on ia64 (and possibly other 64-bit platforms) due to the
> fact that NULL is defined as 0.
>
> Since Erik thinks 0 and 0L are both perfectly good definitions for
> NULL and Tony emphasizes that NULL is an integer expression, I think
^^ may be
> we should change the definition of NULL to 0L to improve portability
> to FreeBSD/LP64. It will definitely fix known breakages on ia64.
This would be bogus. Long doesn't have the same width as `void *' on all
machines. ((void *)0) is better, but I wouldn't change it, except
locally to trap errors. __builtin_null would be better for trapping
errors.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031129161509.J4841>