[vlc-devel] Open issue: timestamp overflows

[Rémi Denis-Courmont]

Le 13 novembre 2017 10:23:36 GMT+02:00, Steve Lhomme <robux4 at gmail.com> a écrit :
>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
>_______________________________________________
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
>https://mailman.videolan.org/listinfo/vlc-devel

No, we can't use configure for public headers. And we probably want this inline for performance reasons.
-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.