<div dir="ltr"><a href="https://github.com/openssl/openssl/pull/2181">https://github.com/openssl/openssl/pull/2181</a><div>and</div><div><a href="https://github.com/openssl/openssl/pull/1603#issuecomment-248649700">https://github.com/openssl/openssl/pull/1603#issuecomment-248649700</a> <br></div><div><br></div><div>One thing that should be noted is that if you are building with -Wall -Werror (which many projects do) and you are using OpenSSL and things change from a const perspective builds break - and that then ends up people having to change code on released versions.</div><div><br></div><div>Adding or removing const changes the API. It doesn't technically change the ABI - although it can impact things as compilers can and do warn for simple const violations in some circumstances. The straight forward "fix" of a cast on call actually doesn't achieve anything useful - in that it simply masks the underlying issue where const was added for a reason.</div><div><br></div><div>We should have a clear policy on doing this sort of thing in released code - either it is okay to do and we should accept patches - or it should never actually be done. I don't see this as a case-by-case basis for determination at all - basically it is a single type of API change we either should be allowing or disallowing.</div><div><br></div><div>There is a similar type of API change which is adding typedefs in for callbacks - which technically also don't change the ABI - and if we allow any form of API change that also could be considered.</div><div><br></div><div>We should discuss this separate from any specific PR and vote to set a policy one way or the other in my view.</div><div><br></div><div>Tim.</div><div><br></div></div>