<html><head></head><body>Sure. But it means that:<br>
1/ The conversion macros will all be only multiplication, or only division, so they will not cause intermediate overflow. If it makes you feel better, add static_assert in mtime.c.<br>
<br>
There are issues in some parts of this patch.<br>
<br>
2/ date_t must be used when the conversion is not to/from a multiple or divisor of CLOCK_FREQ. We cannot do magic.<br><br><div class="gmail_quote">Le 23 juin 2018 07:32:03 GMT+01:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 2018-06-22 9:19 PM, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> As I already pointed out, CLOCK_FREQ must remain a multiple of one <br> million and a divisor of one billion. Too much problems with overflow <br> and rounding otherwise.<br></blockquote><br>100,000,000 is one of these.<br><br><br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><br> Besides POSIX, ISO and Microsoft all agree there.<br><br> Le 22 juin 2018 14:28:08 GMT+01:00, Steve Lhomme <robux4@ycbcr.xyz> a <br> écrit :<br><br> On 2018-06-22 3:17 PM, Romain Vimont wrote:<br><br> On Fri, Jun 22, 2018 at 02:53:26PM +0200, Steve Lhomme wrote:<br><br> Such values currently have a better resolution than<br> vlc_tick_t Also provide conversion macros/functions<br> to/from vlc_tick_t --- include/vlc_tick.h | 18<br> ++++++++++++++++++ 1 file changed, 18 insertions(+) diff<br> --git a/include/vlc_tick.h b/include/vlc_tick.h index<br> 9e7f909e149..6953ba346d4 100644 --- a/include/vlc_tick.h<br> +++ b/include/vlc_tick.h @@ -138,6 +138,24 @@ static<br> inline int64_t ns_from_vlc_tick(vlc_tick_t vtk) return vtk<br> * INT64_C(1000000000) / CLOCK_FREQ; } +/** + * Typically<br> Microsoft time with 100ns resolutions + */ +typedef<br> int64_t msftime_t; +#define MSFTIME_FROM_VLC_TICK(vtk)<br> ((msftime_t)((vtk) * (INT64_C(10000000) / CLOCK_FREQ)))<br> +#define VLC_TICK_FROM_MSFTIME(msft) ((vlc_tick_t)((msft)<br> / (INT64_C(10000000) / CLOCK_FREQ))) +#define<br> MSFTIME_FROM_SEC(sec) ((msftime_t)((sec) *<br> INT64_C(10000000))) /* seconds in msftime_t */ + +static<br> inline vlc_tick_t vlc_tick_from_msftime(msftime_t t) +{ +<br> return t * CLOCK_FREQ / INT64_C(10000000); <br><br> The order of operations is not the same as in the macro, so in<br> theory the results (in extreme cases) might be different. If<br> 10000000 is a multiple of CLOCK_FREQ, the macro implementation<br> is always better (less overflows). In practice, this is<br> probably not important. <br><br><br> It doesn't overflow because of the current value of CLOCK_FREQ. If<br> CLOCK_FREQ changes (to 100,000,000 for example) then the macro is doing<br> division by 0. The function is correct except it might overflow.<br><br> To avoid this I would like the add static asserts in the various<br> functions added by these patches. But that means moving the code. Or<br> putting the assert somewhere else (with relevant explanation).<br><br> We could also do some #if depending on CLOCK_FREQ > divider or not and<br> do the operations the other way around in that case.<br><br> +} + +static inline msftime_t<br> msftime_from_vlc_tick(vlc_tick_t vtk) +{ + return vtk *<br> INT64_C(10000000) / CLOCK_FREQ; +} +<br> /*****************************************************************************<br> * MSTRTIME_MAX_SIZE: maximum possible size of mstrtime<br> *****************************************************************************<br> -- 2.17.0<br><hr><br> vlc-devel mailing list To unsubscribe or modify your<br> subscription options:<br> <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a> <br><br><hr><br> vlc-devel mailing list To unsubscribe or modify your<br> subscription options:<br> <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a> <br><br><br><hr><br><br> vlc-devel mailing list<br> To unsubscribe or modify your subscription options:<br> <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br><br><br> -- <br> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez <br> excuser ma brièveté.<br><br><br><hr><br> vlc-devel mailing list<br> To unsubscribe or modify your subscription options:<br> <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></blockquote><br><hr><br>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>
-- <br>
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>