Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 May 1998 20:35:07 +0200 (SAT)
From:      Robert Nordier <rnordier@nordier.com>
To:        dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?=)
Cc:        bde@zeta.org.au, eivind@yes.no, rnordier@nordier.com, current@FreeBSD.ORG
Subject:   Re: Replacing gcc as the system compiler
Message-ID:  <199805281835.UAA26210@ceia.nordier.com>
In-Reply-To: <xzpra1ecu9h.fsf@gjallarhorn.ifi.uio.no> from =?ISO-8859-1?Q?Dag=2DErling_Coidan_Sm=F8rgrav?= at "May 28, 98 05:03:38 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Coidan Smørgrav wrote:

> Bruce Evans <bde@zeta.org.au> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805281835.UAA26210>