[vlc-devel] [RFC PATCH] vlc_config: add macro denoting the maximum timestamp

Filip Roséen filip at atch.se
Sun Oct 16 22:12:48 CEST 2016


Hi Rémi,

On 2016-10-16 23:02, Rémi Denis-Courmont wrote:

> Le sunnuntaina 16. lokakuuta 2016, 21.18.30 EEST Filip Roséen a écrit :
> > This macro can be used to create a timestamp as far away in the future
> > as possible. Former implementations used INT64_MAX directly, meaning
> > that if we in the future decide to change the type of "mtime_t", we
> > would have to change every usage of INT64_MAX for the related
> > variables.
> 
> There isn´t a larger integer type available and we definitely can´t shrink it, 
> so err? FWIW, the current range exceeds a quarter of a million years.

I did not propose changing the type, the primarily purpose of the
patch is to make it easier to reason about cases that deals with
timestamps (I mentioned type modification because it helps in that
regard too). VLC_TS_MAX, at least in my opinion, is easier to reason
about than seeing INT64_MAX.

> > These changes simply provides a macro that everyone can use, as well
> > as replacing former usage of INT64_MAX with VLC_TS_MAX.
> 
> It won´t work. There are also plenty of INT64_C() and int64_t also involved in 
> time calculation. We also have lldiv() relying on long long being at least as 
> large as mtime_t. And who knows what I forget.

Maybe I should have mentioned the now stated in the commit message,
but I honestly thought that was implied; but I do not care that much
about, though I see the patch as a "nice to have".

I remember when I started jumping around in the codebase, seeing
INT64_MAX got me a little bit confused at first, because it wasn't
immediate obvious that it had a strong correlation to mtime_t.

The primarily reason for the patch was readability, but it is
certainly a minor "issue", and the patch is marked as RFC for that
specific reason.

> Also we can´t even increase the range because a lot of code depends on 
> CLOCK_FREQ being one million in subtle or not so subtle ways. Then again, 
> while I appreciate that certain use cases require higher precision, multimedia 
> timestamping really does not.
> 
> So this seems like a complete and utter waste of time.

Noted, and thanks for the input - it is always appreciated.

> -- 
> Rémi Denis-Courmont
> Nonsponsored VLC developer
> http://www.remlab.net/CV.pdf
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20161016/3a41a997/attachment.html>


More information about the vlc-devel mailing list