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 -- To unsubscribe from this list: 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