<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>