Re: What's in git.git

From: Linus Torvalds <torvalds@osdl.org>
Date: Jun 27, 2006, 06:29 UTC
Message-ID: <Pine.LNX.4.64.0606262321270.3927@g5.osdl.org>
In-Reply-To: <7vpsgvf8jf.fsf@assigned-by-dhcp.cox.net>

On Mon, 26 Jun 2006, Junio C Hamano wrote:

Show 11 quoted lines

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