<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta name="generator" content="pandoc" />
<title></title>
<style type="text/css">code{white-space: pre;}</style>
</head>
<body>
<p>Hi Rémi,</p>
<p>On 2016-10-16 23:02, Rémi Denis-Courmont wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> Le sunnuntaina 16. lokakuuta 2016, 21.18.30 EEST Filip Roséen a écrit :</code></pre>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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.</code></pre>
</blockquote>
<pre><code> 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.</code></pre>
</blockquote>
<p>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.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> These changes simply provides a macro that everyone can use, as well
as replacing former usage of INT64_MAX with VLC_TS_MAX.</code></pre>
</blockquote>
<pre><code> 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.</code></pre>
</blockquote>
<p>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”.</p>
<p>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.</p>
<p>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.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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.</code></pre>
</blockquote>
<p>Noted, and thanks for the input - it is always appreciated.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> --
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</code></pre>
</blockquote>
</body>
</html>