On 10/05/2014 2:35 AM, Brian McGroarty wrote: > On Fri, May 9, 2014 at 8:43 AM, Nicky D. <sl.nicky...@googlemail.com > <mailto:sl.nicky...@googlemail.com>> wrote: > > True, but on the other hand, you'd never call array[i] with i > out of > array bound (it would be a bug, and throwing an exception via > the use > of at(i) is no better than "undefined behaviour" > > that will also lead to a crash in the end). > > > Wrong. See Heartbleed. > > > Slight tangent, but I love these kinds of shares: > > http://article.gmane.org/gmane.os.openbsd.misc/211963 > http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf > http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse > > tl;dr: Heartbleed persisted for so long because even though checking > existed, the OpenSSL engineers built their own heap management that > sat on top of anything provided by the OS and compiler vendors' > libraries. Then, nobody created a unit test or other check that > validated behavior without their heap management in place. It should > be The Least-Surprising Thing Ever that the library then became > uncompileable without the less secure heap manager. > > I don't see an argument for an expensive extra check in production > builds in either HeartBleed or our own use of vectors. Rather, making > sure the case is covered in unit tests and/or debug builds could save > the day. > Totally agree. There's no need (or desirability) to check constantly in production code, if you can achieve the same results with proper testing. Solid foundations don't /guarantee /a solid structure, but shaky foundations /always /undermine any structure you try put on top of it.
The important thing is to make sure that constant bounds-checking in production code is never /necessary/.
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
