Date: Sat, 29 Nov 2003 12:53:49 +0100 (CET) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Bruce Evans <bde@zeta.org.au> Cc: Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: 64-bit NULL: a followup Message-ID: <20031129124129.Q46692@beagle.fokus.fraunhofer.de> In-Reply-To: <20031129161509.J4841@gamplex.bde.org> References: <20031129005823.GA20090@dhcp01.pn.xcllnt.net> <20031129161509.J4841@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 29 Nov 2003, Bruce Evans wrote: BE>On Fri, 28 Nov 2003, Marcel Moolenaar wrote: BE> BE>> Notice the "st8". Since NULL is a pointer constant, programmers do BE>> (implicitly) expect it to have the same width as a pointer type and BE>> thus do not cast it to a pointer type or an integer type that has a BE>> width larger or equal to a pointer type. BE> BE>FreeBSD programmers would never do that ;-), since style(9) requires BE>casting of NULL in function args and mentions this point. (This part BE>of style(9) was written before everything in FreeBSD was prototyped, BE>so the cast was required even for non-variadic functions.) A couple of weeks ago I searched the tree for occurences of execl with missing casts. There is still one occurence in our sources. There are several in contrib. I have contact most authors and all of them have fixed it (except the gdb people - no answer from the up to now). Problematic are nvi (the maintainer said he'll fix it, but doesn't know whether there will be another version of nvi) and bind. The bind in our tree isn't maintened anymore by ISC and bind 9 doesn't have execv(). All that said, I think whether we change the definition or not it's always best to contact the original authors. BE> BE>> So, the bottomline is that we currently do have third-party code that BE>> fails to run on ia64 (and possibly other 64-bit platforms) due to the BE>> fact that NULL is defined as 0. BE>> BE>> Since Erik thinks 0 and 0L are both perfectly good definitions for BE>> NULL and Tony emphasizes that NULL is an integer expression, I think BE> ^^ may be BE>> we should change the definition of NULL to 0L to improve portability BE>> to FreeBSD/LP64. It will definitely fix known breakages on ia64. BE> BE>This would be bogus. Long doesn't have the same width as `void *' on all BE>machines. ((void *)0) is better, but I wouldn't change it, except BE>locally to trap errors. __builtin_null would be better for trapping BE>errors. Yes. Best would be if gcc complains when applying a default promotion to __builtin_null. But hacking gcc was a disgusting experience last time I did it (around 2.5 or 2.6). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031129124129.Q46692>