On Debug build with VS2010 professional array bounds checking is at link.
The first check is a library debug level check. So, if you compile the viewer
debug and don't have prebuilt libraries that are also debug built at the same
level the link stops with file.obj is at a different level than ilb.obj---
Some pre built libs are not available as debug.
On Saturday, May 10, 2014 12:15 AM, Tateru Nino <tateru.n...@gmail.com> wrote:
>
>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> 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
>
>_______________________________________________
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
