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

[Timo Hirvonen <tihirvon@gmail.com>]

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

> 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/