Re: [PATCH] Use explicit pointers for execl...() sentinels.
- From
- Mark Wooding <mdw@distorted.org.uk>
- Date
- Mar 12, 2006, 17:32 UTC
- Message-ID
- <slrne18mq3.fr9.mdw@metalzone.distorted.org.uk>
- In-Reply-To
- <20060312171316.39d138f8.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> wrote:
> NULL should always be ((void *)0).
Says who? I already gave chapter and verse for what NULL is required to do.
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'.
> What 64-bit systems declare NULL as plain 0 (not 0L)?
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
> 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.
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.
(Besides, I don't find bare or casted `0' unreadable. Maybe I'm just strange.)
-- [mdw]