From: Jonathan Tan Date: Mon, 19 Dec 2016 20:54:15 GMT Subject: Re: [PATCH] mailinfo.c: move side-effects outside of assert Message-ID: In-Reply-To: On 12/19/2016 12:38 PM, Kyle J. McKay wrote: > On Dec 19, 2016, at 12:03, Jeff King wrote: > >> On Sat, Dec 17, 2016 at 11:54:18AM -0800, Kyle J. McKay wrote: >> >>> Since 6b4b013f18 (mailinfo: handle in-body header continuations, >>> 2016-09-20, v2.11.0) mailinfo.c has contained new code with an >>> assert of the form: >>> >>> assert(call_a_function(...)) Thanks for spotting this - I'm not sure how I missed that. >> This is obviously an improvement, but it makes me wonder if we should be >> doing: >> >> if (!check_header(mi, &mi->inbody_header_accum, mi->s_hdr_data)) >> die("BUG: some explanation of why this can never happen"); >> >> which perhaps documents the intended assumptions more clearly. A comment >> regarding the side effects might also be helpful. > > I wondered exactly the same thing myself. I was hoping Jonathan would > pipe in here with some analysis about whether this is: > > a) a super paranoid, just-in-case, can't really ever fail because by > the time we get to this code we've already effectively validated > everything that could cause check_header to return false in this case > > -or- > > b) Yeah, it could fail in the real world and it should "die" (and > probably have a test added that triggers such death) > > -or- > > c) Actually, if check_header does return false we can keep going > without problem > > -or- > > d) Actually, if check_header does return false we can keep going by > making a minor change that should be in the patch > > I assume that since Jonathan added the code he will just know the answer > as to which one it is and I won't have to rely on the results of my > imaginary analysis. ;) The answer is "a". The only time that mi->inbody_header_accum is appended to is in check_inbody_header, and appending onto a blank mi->inbody_header_accum always happens when is_inbody_header is true (which guarantees a prefix that causes check_header to always return true). Peff's suggestion sounds reasonable to me, maybe with an error message like "BUG: inbody_header_accum, if not empty, must always contain a valid in-body header".