<div dir="ltr">We don't have a formal policy of no NULL checks - we just have a few members that think we should have such a policy but it has never been voted on as we had sufficiently varying views for a consensus approach to not be possible.<div><br></div><div>Personally I'm in favour of high-level APIs having NULL checks as it (in my experience) leads to less bogus error crash reports from users and simpler handling in error cleanup logic.</div><div>Otherwise you end up writing a whole pile of if(x!=NULL) FOO_free(x); etc </div><div><br></div><div>But it is a style issue.</div><div><br></div><div>However in the context of removing such checks - that we should <b>not</b> be doing - the behaviour of the APIs in this area should not be changed outside of a major version increment - and even then I would not make the change either because it introduces changes which in themselves serve no real purpose - i.e. a style change can result in making a program that used to work fine crash in bad ways - and that we shouldn't be doing even across major version increments in my view.<br><div><br></div><div>Tim.</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 8, 2018 at 8:08 PM, Matt Caswell <span dir="ltr"><<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We've had a policy for a while of not requiring NULL checks in<br>
functions. However there is a difference between not adding them for new<br>
functions and actively removing them for old ones.<br>
<br>
See <a href="https://github.com/openssl/openssl/pull/6893" rel="noreferrer" target="_blank">https://github.com/openssl/<wbr>openssl/pull/6893</a><br>
<br>
In this case the removal of a NULL check in the stack code had the<br>
unintended consequence of a crash in a no-comp build. Is it wise to be<br>
actively removing existing NULL checks like this? It does have an impact<br>
on the behaviour of a function (even if that behaviour is undocumented<br>
and not encouraged). The concern I have is for our API/ABI compatibility<br>
guarantee. If we make changes like this then 1.1.1 may no longer be a<br>
drop in replacement for 1.1.0 for some apps.<br>
<br>
Matt<br>
<br>
______________________________<wbr>_________________<br>
openssl-project mailing list<br>
<a href="mailto:openssl-project@openssl.org">openssl-project@openssl.org</a><br>
<a href="https://mta.openssl.org/mailman/listinfo/openssl-project" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-<wbr>project</a><br>
</blockquote></div><br></div>