From owner-freebsd-current Thu May 28 11:41:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA25381 for freebsd-current-outgoing; Thu, 28 May 1998 11:41:20 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ceia.nordier.com (slip139-92-122-120.joh.za.ibm.net [139.92.122.120]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA25359 for ; Thu, 28 May 1998 11:41:06 -0700 (PDT) (envelope-from rnordier@nordier.com) Received: (from rnordier@localhost) by ceia.nordier.com (8.8.8/8.6.12) id UAA26210; Thu, 28 May 1998 20:35:10 +0200 (SAT) From: Robert Nordier Message-Id: <199805281835.UAA26210@ceia.nordier.com> Subject: Re: Replacing gcc as the system compiler In-Reply-To: from =?ISO-8859-1?Q?Dag=2DErling_Coidan_Sm=F8rgrav?= at "May 28, 98 05:03:38 pm" To: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Thu, 28 May 1998 20:35:07 +0200 (SAT) Cc: bde@zeta.org.au, eivind@yes.no, rnordier@nordier.com, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Coidan Smørgrav wrote: > Bruce Evans writes: > > > There is also what looks like a bug in handling of NULL - it doesn't > > > allow the use of ((void *)0) as NULL for function pointers. > > gcc used to have this bug too. Apparently, the C standard can easily > > be read as not allowing conversion from (void *)0 to a function pointer. > > The standard doesn't allow conversion from an object pointer to a > > function pointer, but (void *)0 is is a null pointer constant and > > null pointer constants are special. > > The C null pointer constant is 0. No cast is needed. Converting 0 to a > function pointer might work better than converting ((void *)0). Bruce is talking about null pointer constants as referred to in the C standard. Both 0 and (void *)0 are equally "null pointer constants" and must work equally well in relevant contexts. > The only situation in which it is advantageous to define NULL as > ((void*)0) instead of just (0) is when passing NULL to a vararg > function which lacks a prototype; but you shouldn't do that anyway, > because it will break on more than just NULL (float->double conversion > for instance) > > With the correct prototypes, it is perfectly legal and semantically > correct to write e.g. > > execl("/bin/sh", "-sh", 0); I'm not sure why you feel the correct prototype int execl(const char *, const char *, ...); has a significant effect in this case. The ellipsis doesn't mean "more of the same", it means "no information as to number and type of parameters is available". Your example may actually fail in environments that have, for example, 16-bit ints and 32-bit pointers (which are, of course, extremely common :-). (That was a troll, wasn't it?) -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message