Timo Hirvonen <tihirvon@xxxxxxxxx> 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] - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html