Re: [PATCH] revision.c: fix possible null pointer access

From: Jeff King <peff@peff.net>
Date: Dec 4, 2015, 23:32 UTC
Message-ID: <20151204233255.GD15064@sigill.intra.peff.net>
In-Reply-To: <xmqq610ete8x.fsf@gitster.mtv.corp.google.com>

On Fri, Dec 04, 2015 at 07:39:10AM -0800, Junio C Hamano wrote:

Show 17 quoted lines

> > But you can't do that computation (in the error case under
> > consideration). Null can't be added to anything (as far as the
> > implications of the standards go). These are horrid gotchas because
> > they go against the grain of all that binary arithmetic and
> > simplifications we learnt long ago.
> 
> Yeah, but in that hunk that does check !tree, because the function
> can be fed a NULL, the computed result assigned to object, which is
> undefined, is never used ;-)
> 
> Of course, there used to be exotic platforms that are still standard
> compliant that triggered a trap when such a pointer computation was
> made (rather, such a bogus pointer was assigned to a pointer
> variable).  I do not think anybody attempted to port Git to such a
> platform, but I agree that it is better to "fix" such a codepath, if
> only to stop wasting time dealing with them discussing with language
> lawyers ;-)

FWIW, I'd worry much more about compilers which do aggressive optimizations based on language-lawyering (e.g., removing the null-check as dead code, which is legal according to the standard because after you computed the pointer based on it, it's all undefined behavior).

I don't think that changes your conclusion, though:

> So as I said in my review, the first hunk is a reject, the second
> one is OK.

-Peff