[vlc-devel] Open issue: timestamp overflows

Rémi Denis-Courmont remi at remlab.net
Sun Nov 12 18:33:17 CET 2017


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