Re: [opensource-dev] Replacement class for LLDynamicArray

[Lance Corrimal]

Hi,

And what did they terll you there? Please share, I'm banging my head against 
the same thing.

Cheers,
LC

Am Donnerstag, 8. Mai 2014, 15:34:39 schrieb Nicky Perian:
> Never mind, got guidance from the #opensl  
> 
> 
> On Thursday, May 8, 2014 4:48 PM, Nicky Perian 
> wrote:
> 
> LLDynamicArray was dropped in viewer-interesting.
> 
> >What is the replacement for it?
> >
> >
> >Nicky
l
___
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

Re: [opensource-dev] Replacement class for LLDynamicArray

[Henri Beauchamp]

On Fri, 09 May 2014 09:24:41 +0200, Lance Corrimal wrote:

> Hi,
> 
> And what did they terll you there? Please share, I'm banging my head against 
> the same thing.
> 
> Cheers,
> LC
> 
> Am Donnerstag, 8. Mai 2014, 15:34:39 schrieb Nicky Perian:
> > Never mind, got guidance from the #opensl  
> > 
> > 
> > On Thursday, May 8, 2014 4:48 PM, Nicky Perian 
> > wrote:
> > 
> > LLDynamicArray was dropped in viewer-interesting.
> > 
> > >What is the replacement for it?
> > >
> > >
> > >Nicky

LLDynamicArray is nothing else than a wrapper around std::vector (it is
probably one of the sequels of a time when the viewer code did not yet
use the C++ standard library, i.e. a "prehistoric" and pre-Open-Souce
time).

Simply replace "LLDynamicArray" with "std::vector array"
and use "array.push_back(Type)" instead of "array.put(Type)",
"array.size()" instead of "array.count()", "array[i]" instead of
"array.get(i), etc...

Henri.
___
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

Re: [opensource-dev] Replacement class for LLDynamicArray

[Nicky Perian]

bring up lldarray.h from the old version. Look at the underlying code for the 
std::vector methods that were wrapped there.
add #include where needed. find std::vector method in the standard. 
using the standard and the old header modify the code.___
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

Re: [opensource-dev] Replacement class for LLDynamicArray

[Nicky Perian]

forgot the link to the standard
 cppreference.com


 
 cppreference.com
optional  (library fundamentals TS) any  (library fundamentals TS) string_view  
(library fundamentals TS) memory_resource  (library fundamentals TS) Filesystem 
library  (filesystem TS)   
View on en.cppreference.com Preview by Yahoo  
  from #opensl  LiruCookies
On Friday, May 9, 2014 5:08 AM, Nicky Perian  wrote:
 
bring up lldarray.h from the old version. Look at the underlying code for the 
std::vector methods that were wrapped there.
>add #include where needed. find std::vector method in the standard. 
>using the standard and the old header modify the code.
>
>
>
>
>
>
>
>
>
>___
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

Re: [opensource-dev] Replacement class for LLDynamicArray

[Nicky Perian]

>"array[i]" instead of "array.get(i), etc...


old code snip  const Type& get(S32 index) const { return 
std::vector::operator[](index); }

Is array[i] same as operator[](i) ?

I notice "operator[](i)" is used in the interesting,

Nicky



On Friday, May 9, 2014 6:14 AM, Nicky Perian  wrote:
 
forgot the link to the standard
> cppreference.com
>
>
> 
> cppreference.com
>optional  (library fundamentals TS) any  (library fundamentals TS) string_view 
> (library fundamentals TS) memory_resource  (library fundamentals TS) 
>Filesystem library  (filesystem TS)   
>View on en.cppreference.com Preview by Yahoo  
>  from #opensl  LiruCookies
>On Friday, May 9, 2014 5:08 AM, Nicky Perian  wrote:
> 
>bring up lldarray.h from the old version. Look at the underlying code for the 
>std::vector methods that were wrapped there.
>>add #include where needed. find std::vector method in the standard. 
>>using the standard and the old header modify the code.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>___
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

Re: [opensource-dev] Replacement class for LLDynamicArray

[Henri Beauchamp]

On Fri, 9 May 2014 05:17:42 -0700 (PDT), Nicky Perian wrote:

> >"array[i]" instead of "array.get(i), etc...
> 
> 
> old code snip  const Type& get(S32 index) const { return 
> std::vector::operator[](index); }
> 
> Is array[i] same as operator[](i) ?

Yep. It's just the way the [] operator is declared in C++. See:
http://www.cplusplus.com/reference/vector/vector/operator%5B%5D/

> I notice "operator[](i)" is used in the interesting,

With std::vector, you could also use array.at(i), which is equivalent.

Henri.
___
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

Re: [opensource-dev] Replacement class for LLDynamicArray

[Nicky D.]

>
>
> > I notice "operator[](i)" is used in the interesting,
>
> With std::vector, you could also use array.at(i), which is equivalent.
>
>
vector::at will do a runtime check if the index is out of bounds, in that
case it throws
an exception.

vector::operator[] will not do this check, causing undefined behavior when
accessing
elements out of bounds.

Nicky
___
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

Re: [opensource-dev] Replacement class for LLDynamicArray

[Lance Corrimal]

Am Freitag, 9. Mai 2014, 15:37:15 schrieb Nicky D.:
> > > I notice "operator[](i)" is used in the interesting,
> > 
> > With std::vector, you could also use array.at(i), which is equivalent.

So what would i do with a items->get(i) (excuse my stupid)?


Cheers
LC
___
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

Re: [opensource-dev] Replacement class for LLDynamicArray

[Nicky Perian]

haven't tried, looks like the best choice is items->array.at(i)



On Friday, May 9, 2014 8:47 AM, Lance Corrimal  
wrote:
 
Am Freitag, 9. Mai 2014, 15:37:15 schrieb Nicky D.:
>> > > I notice "operator[](i)" is used in the interesting,
>> > 
>> > With std::vector, you could also use array.at(i), which is equivalent.
>
>So what would i do with a items->get(i) (excuse my stupid)?
>
>
>Cheers
>LC
>
>___
>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

Re: [opensource-dev] Replacement class for LLDynamicArray

[Ambrosia]

array->at(i), if 'array' is a pointer to a vector.

--Chalice Yao


On Fri, May 9, 2014 at 3:47 PM, Lance Corrimal wrote:

> Am Freitag, 9. Mai 2014, 15:37:15 schrieb Nicky D.:
> > > > I notice "operator[](i)" is used in the interesting,
> > >
> > > With std::vector, you could also use array.at(i), which is equivalent.
>
> So what would i do with a items->get(i) (excuse my stupid)?
>
>
> Cheers
> LC
> ___
> 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

Re: [opensource-dev] Replacement class for LLDynamicArray

[Ambrosia]

make that items->at(i) to match your example.


On Fri, May 9, 2014 at 3:53 PM, Ambrosia  wrote:

> array->at(i), if 'array' is a pointer to a vector.
>
> --Chalice Yao
>
>
> On Fri, May 9, 2014 at 3:47 PM, Lance Corrimal 
> wrote:
>
>> Am Freitag, 9. Mai 2014, 15:37:15 schrieb Nicky D.:
>> > > > I notice "operator[](i)" is used in the interesting,
>> > >
>> > > With std::vector, you could also use array.at(i), which is
>> equivalent.
>>
>> So what would i do with a items->get(i) (excuse my stupid)?
>>
>>
>> Cheers
>> LC
>> ___
>> 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

Re: [opensource-dev] Replacement class for LLDynamicArray

[Ambrosia]

I have a copy of viewer-interesting that I patched with code from my
NaCl-release repo. I can upload it to my repo later so you can see examples
of how I converted custom code to the new types.


On Fri, May 9, 2014 at 3:52 PM, Nicky Perian  wrote:

> haven't tried, looks like the best choice is items->array.at(i)
>
>
>
>   On Friday, May 9, 2014 8:47 AM, Lance Corrimal <
> lance.corri...@eregion.de> wrote:
>
> Am Freitag, 9. Mai 2014, 15:37:15 schrieb Nicky D.:
> > > > I notice "operator[](i)" is used in the interesting,
> > >
> > > With std::vector, you could also use array.at(i), which is equivalent.
>
> So what would i do with a items->get(i) (excuse my stupid)?
>
>
> Cheers
> LC
>
> ___
> 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
>
___
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

Re: [opensource-dev] Replacement class for LLDynamicArray

[Lance Corrimal]

Am Freitag, 9. Mai 2014, 15:54:10 schrieb Ambrosia:
> make that items->at(i) to match your example.
> 
> On Fri, May 9, 2014 at 3:53 PM, Ambrosia  wrote:
> > array->at(i), if 'array' is a pointer to a vector.


Thanks!!!


Cheers,
LC

___
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

Re: [opensource-dev] Replacement class for LLDynamicArray

[Henri Beauchamp]

On Fri, 9 May 2014 15:37:15 +0200, Nicky D. wrote:

> > > I notice "operator[](i)" is used in the interesting,
> >
> > With std::vector, you could also use array.at(i), which is equivalent.
>
> vector::at will do a runtime check if the index is out of bounds, in
> that case it throws an exception.
> 
> vector::operator[] will not do this check, causing undefined behavior
> when accessing elements out of bounds.

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). The fact that array[i] doesn't check the upper
bound also makes it faster than array.at(i): competent programmers who
do check for bounds where actually needed will therefore prefer
array[i] to array.at(i), esspecially when used in a loop !

Henri.
___
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

Re: [opensource-dev] Replacement class for LLDynamicArray

[Nicky D.]

>
> 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.  It depends on if the page behind the last element
is valid and how you use the memory. That's why it is undefined. Because
no one can say.
The exception at least would have terminated the buggy code and not sent
private sessions keys to someone else.
It's buggy no matter what, agreed to that. But at at least in one case it
goes
down right away without happily processing whatever data first.

The fact that array[i] doesn't check the upper
> bound also makes it faster than array.at(i): competent programmers who
> do check for bounds where actually needed will therefore prefer
> array[i] to array.at(i), esspecially when used in a loop !


Agreed.

Nicky
___
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

Re: [opensource-dev] Replacement class for LLDynamicArray

[Brian McGroarty]

On Fri, May 9, 2014 at 6:37 AM, Nicky D.  wrote:

>
>> > I notice "operator[](i)" is used in the interesting,
>>
>> With std::vector, you could also use array.at(i), which is equivalent.
>
>
> vector::at will do a runtime check if the index is out of bounds, in that
> case it throws
> an exception.
>
> vector::operator[] will not do this check, causing undefined behavior when
> accessing
> elements out of bounds.
>

Slight tweak: [] on out of bounds members is undefined, but specific
implementations may still check.

Most (maybe even all) STL implementations support bounds checking with a
compile flag. If anyone's eager to experiment, it would be nice to add that
to the debug build flags and see if debugging performance is still
tolerable on all platforms.

-- 
*Brian McGroarty *| Application Security, Platform Engineering

*Linden Lab* | Makers of Shared Creative Spaces 
___
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

Re: [opensource-dev] Replacement class for LLDynamicArray

[Brian McGroarty]

On Fri, May 9, 2014 at 8:43 AM, Nicky D.  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.

-- 
*Brian McGroarty *| Application Security, Platform Engineering

*Linden Lab* | Makers of Shared Creative Spaces 
___
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

Re: [opensource-dev] Replacement class for LLDynamicArray

[Nicky D.]

>
>
> Slight tweak: [] on out of bounds members is undefined, but specific
> implementations may still check.
>
> Most (maybe even all) STL implementations support bounds checking with a
> compile flag. If anyone's eager to experiment, it would be nice to add that
> to the debug build flags and see if debugging performance is still
> tolerable on all platforms.
>
>
Visual Studio controls this in various forms via
_ITERATOR_DEBUG_LEVEL/_SECURE_SCL and _HAS_ITERATOR_DEBUGGING. To my
knowledge is this enabled for any Windows debug build.

Nicky
___
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

Re: [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.  > 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