From nickyperian at yahoo.com Thu May 8 14:48:50 2014 From: nickyperian at yahoo.com (Nicky Perian) Date: Thu, 8 May 2014 14:48:50 -0700 (PDT) Subject: [opensource-dev] Replacement class for LLDynamicArray Message-ID: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> LLDynamicArray was dropped in viewer-interesting. What is the replacement for it? Nicky -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140508/09c2f6d9/attachment.htm From nickyperian at yahoo.com Thu May 8 15:34:39 2014 From: nickyperian at yahoo.com (Nicky Perian) Date: Thu, 8 May 2014 15:34:39 -0700 (PDT) Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> Message-ID: <1399588479.42685.YahooMailNeo@web161605.mail.bf1.yahoo.com> 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140508/1e445a9b/attachment.htm From Lance.Corrimal at eregion.de Fri May 9 00:24:41 2014 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Fri, 09 May 2014 09:24:41 +0200 Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: <1399588479.42685.YahooMailNeo@web161605.mail.bf1.yahoo.com> References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399588479.42685.YahooMailNeo@web161605.mail.bf1.yahoo.com> Message-ID: <1919918.V4DUWyAzch@sai.eregion.home> 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 From sldev at free.fr Fri May 9 01:25:19 2014 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 9 May 2014 10:25:19 +0200 Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: <1919918.V4DUWyAzch@sai.eregion.home> References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399588479.42685.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1919918.V4DUWyAzch@sai.eregion.home> Message-ID: <20140509102519.d81ab89d.sldev@free.fr> 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. From nickyperian at yahoo.com Fri May 9 03:08:24 2014 From: nickyperian at yahoo.com (Nicky Perian) Date: Fri, 9 May 2014 03:08:24 -0700 (PDT) Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: <20140509102519.d81ab89d.sldev@free.fr> References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399588479.42685.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1919918.V4DUWyAzch@sai.eregion.home> <20140509102519.d81ab89d.sldev@free.fr> Message-ID: <1399630104.63975.YahooMailNeo@web161602.mail.bf1.yahoo.com> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140509/7a96368f/attachment.htm From nickyperian at yahoo.com Fri May 9 04:14:14 2014 From: nickyperian at yahoo.com (Nicky Perian) Date: Fri, 9 May 2014 04:14:14 -0700 (PDT) Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: <1399630104.63975.YahooMailNeo@web161602.mail.bf1.yahoo.com> References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399588479.42685.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1919918.V4DUWyAzch@sai.eregion.home> <20140509102519.d81ab89d.sldev@free.fr> <1399630104.63975.YahooMailNeo@web161602.mail.bf1.yahoo.com> Message-ID: <1399634054.93258.YahooMailNeo@web161605.mail.bf1.yahoo.com> 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. > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140509/15e58e34/attachment-0001.htm From nickyperian at yahoo.com Fri May 9 05:17:42 2014 From: nickyperian at yahoo.com (Nicky Perian) Date: Fri, 9 May 2014 05:17:42 -0700 (PDT) Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: <1399634054.93258.YahooMailNeo@web161605.mail.bf1.yahoo.com> References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399588479.42685.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1919918.V4DUWyAzch@sai.eregion.home> <20140509102519.d81ab89d.sldev@free.fr> <1399630104.63975.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399634054.93258.YahooMailNeo@web161605.mail.bf1.yahoo.com> Message-ID: <1399637862.55247.YahooMailNeo@web161605.mail.bf1.yahoo.com> >"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. >> >> >> >> >> >> >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140509/04e108d6/attachment.htm From sldev at free.fr Fri May 9 06:12:02 2014 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 9 May 2014 15:12:02 +0200 Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: <1399637862.55247.YahooMailNeo@web161605.mail.bf1.yahoo.com> References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399588479.42685.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1919918.V4DUWyAzch@sai.eregion.home> <20140509102519.d81ab89d.sldev@free.fr> <1399630104.63975.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399634054.93258.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1399637862.55247.YahooMailNeo@web161605.mail.bf1.yahoo.com> Message-ID: <20140509151202.f37e5cf0.sldev@free.fr> 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. From sl.nicky.ml at googlemail.com Fri May 9 06:37:15 2014 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Fri, 9 May 2014 15:37:15 +0200 Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: <20140509151202.f37e5cf0.sldev@free.fr> References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399588479.42685.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1919918.V4DUWyAzch@sai.eregion.home> <20140509102519.d81ab89d.sldev@free.fr> <1399630104.63975.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399634054.93258.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1399637862.55247.YahooMailNeo@web161605.mail.bf1.yahoo.com> <20140509151202.f37e5cf0.sldev@free.fr> Message-ID: > > > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140509/8fa4aa1c/attachment.htm From Lance.Corrimal at eregion.de Fri May 9 06:47:25 2014 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Fri, 09 May 2014 15:47:25 +0200 Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <20140509151202.f37e5cf0.sldev@free.fr> Message-ID: <3776178.UpyJMtiY8s@sai.eregion.home> 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 From nickyperian at yahoo.com Fri May 9 06:52:33 2014 From: nickyperian at yahoo.com (Nicky Perian) Date: Fri, 9 May 2014 06:52:33 -0700 (PDT) Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: <3776178.UpyJMtiY8s@sai.eregion.home> References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <20140509151202.f37e5cf0.sldev@free.fr> <3776178.UpyJMtiY8s@sai.eregion.home> Message-ID: <1399643553.47592.YahooMailNeo@web161602.mail.bf1.yahoo.com> 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140509/da419165/attachment-0001.htm From chaosstar at gmail.com Fri May 9 06:53:48 2014 From: chaosstar at gmail.com (Ambrosia) Date: Fri, 9 May 2014 15:53:48 +0200 Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: <3776178.UpyJMtiY8s@sai.eregion.home> References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <20140509151202.f37e5cf0.sldev@free.fr> <3776178.UpyJMtiY8s@sai.eregion.home> Message-ID: 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140509/b51e06f7/attachment.htm From chaosstar at gmail.com Fri May 9 06:54:10 2014 From: chaosstar at gmail.com (Ambrosia) Date: Fri, 9 May 2014 15:54:10 +0200 Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <20140509151202.f37e5cf0.sldev@free.fr> <3776178.UpyJMtiY8s@sai.eregion.home> Message-ID: 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140509/879d13cb/attachment.htm From chaosstar at gmail.com Fri May 9 06:55:38 2014 From: chaosstar at gmail.com (Ambrosia) Date: Fri, 9 May 2014 15:55:38 +0200 Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: <1399643553.47592.YahooMailNeo@web161602.mail.bf1.yahoo.com> References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <20140509151202.f37e5cf0.sldev@free.fr> <3776178.UpyJMtiY8s@sai.eregion.home> <1399643553.47592.YahooMailNeo@web161602.mail.bf1.yahoo.com> Message-ID: 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.Corrimal at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140509/f95acc6e/attachment.htm From Lance.Corrimal at eregion.de Fri May 9 06:59:50 2014 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Fri, 09 May 2014 15:59:50 +0200 Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> Message-ID: <1522332.6jipkPfJI8@sai.eregion.home> 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 From sldev at hotmail.com Fri May 9 08:12:07 2014 From: sldev at hotmail.com (Henri Beauchamp) Date: Fri, 9 May 2014 17:12:07 +0200 Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399588479.42685.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1919918.V4DUWyAzch@sai.eregion.home> <20140509102519.d81ab89d.sldev@free.fr> <1399630104.63975.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399634054.93258.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1399637862.55247.YahooMailNeo@web161605.mail.bf1.yahoo.com> <20140509151202.f37e5cf0.sldev@free.fr> Message-ID: <20140509171207.17d1f272.sldev@hotmail.com> 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. From sl.nicky.ml at googlemail.com Fri May 9 08:43:34 2014 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Fri, 9 May 2014 17:43:34 +0200 Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: <20140509171207.17d1f272.sldev@hotmail.com> References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399588479.42685.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1919918.V4DUWyAzch@sai.eregion.home> <20140509102519.d81ab89d.sldev@free.fr> <1399630104.63975.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399634054.93258.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1399637862.55247.YahooMailNeo@web161605.mail.bf1.yahoo.com> <20140509151202.f37e5cf0.sldev@free.fr> <20140509171207.17d1f272.sldev@hotmail.com> Message-ID: > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140509/9f064e94/attachment.htm From soft at lindenlab.com Fri May 9 09:20:30 2014 From: soft at lindenlab.com (Brian McGroarty) Date: Fri, 9 May 2014 09:20:30 -0700 Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399588479.42685.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1919918.V4DUWyAzch@sai.eregion.home> <20140509102519.d81ab89d.sldev@free.fr> <1399630104.63975.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399634054.93258.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1399637862.55247.YahooMailNeo@web161605.mail.bf1.yahoo.com> <20140509151202.f37e5cf0.sldev@free.fr> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140509/621b8790/attachment-0001.htm From soft at lindenlab.com Fri May 9 09:35:56 2014 From: soft at lindenlab.com (Brian McGroarty) Date: Fri, 9 May 2014 09:35:56 -0700 Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399588479.42685.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1919918.V4DUWyAzch@sai.eregion.home> <20140509102519.d81ab89d.sldev@free.fr> <1399630104.63975.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399634054.93258.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1399637862.55247.YahooMailNeo@web161605.mail.bf1.yahoo.com> <20140509151202.f37e5cf0.sldev@free.fr> <20140509171207.17d1f272.sldev@hotmail.com> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140509/74f1693e/attachment.htm From sl.nicky.ml at googlemail.com Fri May 9 10:23:32 2014 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Fri, 9 May 2014 19:23:32 +0200 Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399588479.42685.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1919918.V4DUWyAzch@sai.eregion.home> <20140509102519.d81ab89d.sldev@free.fr> <1399630104.63975.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399634054.93258.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1399637862.55247.YahooMailNeo@web161605.mail.bf1.yahoo.com> <20140509151202.f37e5cf0.sldev@free.fr> Message-ID: > > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140509/0ad5b2a5/attachment.htm From tateru.nino at gmail.com Fri May 9 22:14:38 2014 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat, 10 May 2014 15:14:38 +1000 Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399588479.42685.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1919918.V4DUWyAzch@sai.eregion.home> <20140509102519.d81ab89d.sldev@free.fr> <1399630104.63975.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399634054.93258.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1399637862.55247.YahooMailNeo@web161605.mail.bf1.yahoo.com> <20140509151202.f37e5cf0.sldev@free.fr> <20140509171207.17d1f272.sldev@hotmail.com> Message-ID: <536DB5BE.5050709@gmail.com> 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/. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140510/a94a98c0/attachment.htm From nickyperian at yahoo.com Sun May 11 11:32:06 2014 From: nickyperian at yahoo.com (Nicky Perian) Date: Sun, 11 May 2014 11:32:06 -0700 (PDT) Subject: [opensource-dev] Another std::vector array ? Message-ID: <1399833126.26969.YahooMailNeo@web161606.mail.bf1.yahoo.com> ?-obj_item_array.remove(idxItem); ?+obj_item_array.erase(obj_item_array.begin()+(idxItem)); ?? Is the correct change to remove an item? maybe obj_item_array.pop_back(idxItem); ?is this better looks like the above is a contents erase. Nicky -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140511/67bebf9c/attachment.htm From nickyperian at yahoo.com Mon May 12 09:31:28 2014 From: nickyperian at yahoo.com (Nicky Perian) Date: Mon, 12 May 2014 09:31:28 -0700 (PDT) Subject: [opensource-dev] Replacement class for LLDynamicArray In-Reply-To: <536DB5BE.5050709@gmail.com> References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399588479.42685.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1919918.V4DUWyAzch@sai.eregion.home> <20140509102519.d81ab89d.sldev@free.fr> <1399630104.63975.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399634054.93258.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1399637862.55247.YahooMailNeo@web161605.mail.bf1.yahoo.com> <20140509151202.f37e5cf0.sldev@free.fr> <20140509171207.17d1f272.sldev@hotmail.com> <536DB5BE.5050709@gmail.com> Message-ID: <1399912288.59857.YahooMailNeo@web161603.mail.bf1.yahoo.com> 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 wrote: > >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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140512/65d65e0b/attachment.htm From sldev at free.fr Tue May 20 02:26:41 2014 From: sldev at free.fr (Henri Beauchamp) Date: Tue, 20 May 2014 11:26:41 +0200 Subject: [opensource-dev] MemPlugs viewer sources In-Reply-To: <536DB5BE.5050709@gmail.com> References: <1399585730.71143.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399588479.42685.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1919918.V4DUWyAzch@sai.eregion.home> <20140509102519.d81ab89d.sldev@free.fr> <1399630104.63975.YahooMailNeo@web161602.mail.bf1.yahoo.com> <1399634054.93258.YahooMailNeo@web161605.mail.bf1.yahoo.com> <1399637862.55247.YahooMailNeo@web161605.mail.bf1.yahoo.com> <20140509151202.f37e5cf0.sldev@free.fr> <20140509171207.17d1f272.sldev@hotmail.com> <536DB5BE.5050709@gmail.com> Message-ID: <20140520112641.e419f1bb.sldev@free.fr> Greetings, Could we please get public access to the repository for the "Second Life MemPlugs Viewer" which is listed in the Alternate_Viewers Wiki page (https://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers) but which corresponding repository (https://bitbucket.org/account/signin/?next=/lindenlabinternal/viewer-drtvwr-365), listed in Viewer_Source_Repositories in the Wiki is closed, even after logging in into bitbucket ? Henri.