[vlc-devel] Open issue: timestamp overflows

[Steve Lhomme]

On Sun, Nov 12, 2017 at 6:33 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
>         Hello,
>
> One outstanding issue from this week-end's developers workshop is handling of
> overflow in timestamp-related computation,
>
> Most typically, timestamps have to be scaled from some input format rate, to
> the fixed VLC microseconds. This is a problem because it can overflow.
> Furthermore, VLC timestamps are signed (because some corner cases require it),
> leading to undefined behaviour. Luckily, this has proven largely
> inconsequential so far because the compiler cannot really optimize it "wrong".
>
> Unfortunately, there is no easy way to check for signed multiplication overflow
> in standard C. On GCC and Clang, the overflow built-ins can do it. On compilers
> with 128-bits arithmetic, the multiplication can be done in 128-bits domain.
> However, we have no ways to check for 128-bits support, and some compilers
> might not even have it.

On detection, we can add a check in configure.ac to detect if the
compiler actually handles timestamp handling that might overflow. It's
not really a matter of 128 bits but rather if the compiler is safe or
not.

> This leads to two and a half questions:
>
> 1.a) What do we do if timestamp overflows? IMO, adding error cases is overkill.
> We should allow timestamp to wrap around.

What kind of error are we dealing with here ? AFAIK timestamp
multiplication cannot happen (I don't see how it would make sense). So
it's rather additions and multiplications.

For additions it wouldn't make sense to add two timestamps together,
it should be with a relative value. In that case overflow would happen
if the timestamp value is close to its max or the delta value is very
bogus.

For subtractions it doesn't seem to be a problem. You can subtract a
timestamp or a delta. With a timestamp I don't think it can overflow
but it can become negative (makes sense to get a delta). And with a
delta it can't overflow either even with a very large value.

So the only overflow case we really have to check is adding two real
timestamps. But does it even make sense to use that ? Do we have that
in the code ?

> 1.b) Do we switch everything to date_t and handle scaling there? Do we add a
> dedicated helper to rescale timestamps?
>
> 2) How do we detect it in the first place? So far, we only have a good solution
> for GCC and Clang. Do we drop standard conformance? Do we allow minor UB
> issues on other compilers? Do we implement the check the hard way? Or do we do
> nothing at all?
>
> --
> Rémi Denis-Courmont
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel