On Sun, 12 Mar 2006 17:32:51 +0000 (UTC) Mark Wooding <mdw@xxxxxxxxxxxxxxxx> 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/ - : 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