[opensource-dev] Question about BUG-41029 and 64 bit usage

Richard Nelson richard at lindenlab.com
Fri Dec 16 11:14:59 PST 2016


FWIW, those particular units types were introduced as part of the LLTrace  
metrics update and found several cases where the incorrect units were  
being recorded, resulting in skewed/invalid metrics.  The point is not  
that it is hard to multiply by a constant to do unit conversion...it is  
that programmers sometimes forget to, so it is hard to know how much you  
can trust metrics that have not been thoroughly vetted in the code.

On Fri, 16 Dec 2016 00:44:51 -0800, Henri Beauchamp <sldev at free.fr> wrote:

> On Thu, 15 Dec 2016 11:13:35 -0800, Callum Prentice (Callum) wrote:
>
>> https://jira.secondlife.com/browse/BUG-41029
>>
>> .../...
>>
>> There is a lot usage of 32 bit types (U32Bytes, U32Megabytes etc.)  
>> defined
>> indirectly here:
>>
>> https://bitbucket.org/lindenlab/viewer64/src/9270caf3d4324f9c1c33aa158f80e0fe84036a48/indra/llcommon/llunittype.h?at=default&fileviewer=file-view-default#llunittype.h-824
>>
>> that are used to count memory sizes/usage/difference etc.  I think we  
>> can
>> convert them to their U64 equivalents for all viewers.
>>
>> Nat points out, rewriting this code using size_t as a return type would
>> make more sense but that seems like it would involve more invasive code
>> changes including changes in fundamental LL headers.
>>
>> What does the collective wisdom say?
>
> My *personal* wisdom says that this U32Bytes/U32Megabytes templatized
> thingy is just the expression of the lazyness of its coder (frankly,
> is it *that* difficult to use a constant multiplier to convert from
> bytes to megabytes ?) and just adds more complexity to the generated
> code without any benefit whatsoever.
>
> As a result, I did not backport this non-sense to the Cool VL Viewer
> and kept everything in normal variables (U32 for megabytes, U64 for
> bytes, etc), using constants to convert from one unit to the other
> when needed; my viewer is therefore unafffected by that bug...
>
> My advice would therefore be to revert the corresponding commit.
>
> 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


-- 
Festina Lente


More information about the opensource-dev mailing list