Re: [PATCH] Use explicit pointers for execl...() sentinels.

From: Timo Hirvonen <tihirvon@gmail.com>
Date: Mar 12, 2006, 18:08 UTC
Message-ID: <20060312200812.3fb04638.tihirvon@gmail.com>
In-Reply-To: <slrne18mq3.fr9.mdw@metalzone.distorted.org.uk>

On Sun, 12 Mar 2006 17:32:51 +0000 (UTC) Mark Wooding <mdw@distorted.org.uk> wrote:

Show 5 quoted lines

> Besides, (void *)0 fixes /this particular/ problem, because `void *' and
> `char *' have the same representation (6.2.5#27).  This wouldn't help us
> with a putative function which takes an arbitrary number of `foo *'
> pointers, since nothing guarantees that `void *' and `foo *' have
> similar representations.  You'd have to say `(foo *)0' or `(foo *)NULL'.

NULL pointer does not point to any data, it just says it's 'empty'. So it doesn't need to be same type pointer as specified in the function prototype. Pointers are just addresses, it doesn't matter from to code generation point of view whether it is (char *)0 or (void *)0.

> Don't know: didn't look.  0L won't do the right thing with IL32LLP64, if
> anyone was actually crazy enough to specify such an ABI.  The point is,
> there's not much

sizeof(unsigned long) is sizeof(void *) in real world.

> > How about fixing those systems instead of making the git source code
> > unreadable.
> 
> Because, according to the C and POSIX specs, they're not wrong.

They didn't think of 64-bit architectures back then, I suppose.

> The right fix from the point of view of a C implementation would be to
> define NULL to be some weird __null_pointer token which the compiler
> could warn about whenever it was used in an untyped argument context.

In practice (void *)0 is good enough.

> (Besides, I don't find bare or casted `0' unreadable.  Maybe I'm just
> strange.)

'ugly' would have been better word than 'unreadable'.

-- 
http://onion.dynserv.net/~timo/