[opensource-dev] Replacement class for LLDynamicArray

[Tateru Nino]

On 10/05/2014 2:35 AM, Brian McGroarty wrote:
> On Fri, May 9, 2014 at 8:43 AM, Nicky D. <sl.nicky.ml at googlemail.com
> <mailto:sl.nicky.ml at 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/.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140510/a94a98c0/attachment.htm