[vtkusers] Moving an actor, after about 1.5 hours.

[David Gobbi]

To say "all bets are off" is ludicrous. Compilers everywhere use two's
complement arithmetic where there is no difference (at the bit level)
between signed and unsigned addition.  So it's a darn good bet, if you're
trying to predict how the system is going to behave.

On Wed, Mar 9, 2016 at 2:40 PM, Sean McBride <sean at rogue-research.com>
wrote:

> Not necessarily.  vtkAtomicInt32 is signed, and signed overflow is
> undefined in C++.  So once the ++ operator overflows GlobalTimeStamp, all
> bets are off.
>
> clang's UBSan could catch this at runtime:
>
> <http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html>
>
> but I'm not sure if it works on Windows.
>
> Sean
>
>
>
> On Tue, 8 Mar 2016 06:47:16 -0700, David Gobbi said:
>
> >Since only the low 32 bits are kept (the high bits are simply discarded),
> >the wrap-around of the ModifiedTime is exactly the same as if a 32-bit
> >unsigned integer was being incremented.
> >
> > - David
> >
> >On Tue, Mar 8, 2016 at 6:27 AM, Richard Frank <rickfrank at me.com> wrote:
> >
> >> Actually, it's a bit stranger than I thought. The global time stamp on
> >> Windows 64 bit is a 64 bit int cast to an
> >> Unsigned long, as size of void ptr is 8
> >> void vtkTimeStamp::Modified()
> >> {
> >> #if VTK_SIZEOF_VOID_P == 8
> >> static vtkAtomicInt64 GlobalTimeStamp(0);
> >> #else
> >> static vtkAtomicInt32 GlobalTimeStamp(0);
> >> #endif
> >> this->ModifiedTime = (unsigned long)++GlobalTimeStamp;
> >> }
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160309/e7efc50c/attachment.html>