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

[Jeff King <peff@peff.net>]

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

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