[vlc-devel] Open issue: timestamp overflows
Rémi Denis-Courmont
remi at remlab.net
Sun Nov 12 18:33:17 CET 2017
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.
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.
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
More information about the vlc-devel
mailing list