On Mon, 26 Jun 2006, Junio C Hamano wrote: > > As long as none of the following does not dereference the NULL > pointer that should work fine: > > - memchr(NULL, ch, 0); > > - memcmp(NULL, ptr, 0); > > - stream.next_in = NULL; > stream.avail_in = 0; > deflate(&stream, Z_FINISH); Well, they clearly _shouldn't_, but bugs happen in libraries too. (The reason they shouldn't is simple: replace the NULL pointer with a perfectly normal pointer at the end of a page, and if you access past the length of the memory area, you'd get the same SIGSEGV that a NULL pointer should give you). So the question is how much to trust the libraries for a special case that has a clearly "Right Answer", but is probably unusual in practice. (That said, "malloc(0)" can validly return NULL, so the NULL+<zero length> thing can really happen in real code even if it's not explicit). If people want to be anally defensive, we should give it a valid pointer. If there are known buggy libraries, I wouldn't object to something explicit like #define DUMMYPTR ((void *)"") and hide it that way - the code may be the exact same thing that I objected to, but now you're showing that you know that the cast is crud, and you're just wanting to pass in some non-NULL valid pointer that can be dereferenced but never written to. Personally, I think NULL is much better, until somebody shows an actual buggy library. Linus - : 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