<html><head></head><body>There are no such thing as an "other way". If you hide the unit of the time type, then you have to expose the unit of the conversions to and from it.<br>
<br>
Milli is not a unit. It's a fixed point representation. If you use tick as the unit, then milli means millitick, not millisecond. Talk about confusing.<br>
<br>
On top of that, ms/us/ns are shorter than milli/micro/nano.<br><br><div class="gmail_quote">Le 18 juin 2018 09:58:14 GMT+03: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-16 10:53 AM, 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;"> Le lauantaina 16. kesäkuuta 2018, 11.32.50 EEST Steve Lhomme a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> On 2018-06-16 10:23 AM, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> Le lauantaina 16. kesäkuuta 2018, 10.34.18 EEST Steve Lhomme a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> I used milli instead of ms so it's not confused with msftime_t. And so<br> micro and nano seems like logical siblings.<br></blockquote> Then keep mtime and screw this series.<br></blockquote> I find mtime misleading. Especially because it assumes a certain value<br> and in many parts of the code 1000 or 1000000 is used instead of proper<br> conversion because what could possibly go wrong ?<br></blockquote> Well, these things regularly go wrong:<br> - failing to convert, typically the caching values between ms and µs,<br> - failing to expand before computation, typically from 32-bits to 64-bits.<br><br> mtime_t is not a particularly good name, but it's anyway assumed same as<br> int64_t all over the place, so the name does not matter than much.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> With a tick (or something else) you know you have to take care of a<br> conversion in the proper time format you're handling.<br></blockquote> But that's exactly the point. If you use tick, jiffy or whatever other non-<br> standard unit, then you have to define what the other unit is.<br></blockquote><br>I see it the other way. One should not know what a tick is nor the <br>precision it can have. The API around it should hide all the <br>intricacies. The fact the name implies it's in microseconds lead to a <br>lot of dirty code we have right now.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> That's why ns, us/µs, ms are far better names than nano, micro and milli.<br></blockquote><br>I would like nsec, msec and µsec but it's not possible and using ms may <br>lead to confusion. And us doesn't sound anything like µs it just looks <br>the same.<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> mtime_t will stay for backward compatibility but IMO it should not be<br> used anymore.<br></blockquote> I don't mind changing the name to something short and correctly namespaced.<br> But it would be utterly vain in any case. The code assumes int64_t in a<br> variety of subtle and not-so-subtle ways, no matter the typedef alias.<br></blockquote><br>This is all fixed. See <a href="https://code.videolan.org/robUx4/vlc/tree/clock/43">https://code.videolan.org/robUx4/vlc/tree/clock/43</a><br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> As far as I am concerned, if you don't specify the time unit in a computer<br> program, you are using local jiffies, not seconds. Talk about confusing.<br><br> ISO C uses nsec, not nano. SI uses ms, µs and ns with us as the defacto<br> standard transliteration of µs.<br></blockquote> We could use nsec instead of nano to align with the standard. But then<br> msec could be either milliseconds or microseconds.<br></blockquote> Not really. VLC did confuse m for micro. But in the standards, it's always u/µ<br> for micro and m for milli.</blockquote><br><br>I don't like it. But if everyone agrees on this fine. I can change that <br>easily in my patches.<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>