<div dir="ltr">A bit of input from a user here. I've never seen code handle timestamp aliasing properly until its been painstakingly debugged in the wild. Most developers assume that if a file is newer than another its timestamp will be > than the other. More accurate timestamps don't solve the root issue, but they dramatically reduce the probability of it getting hit in the wild. In general file system operations are going to be dominated by IO so it seems like in this case maximum correctness should win. Even on 32-bit I can't imagine the 128 bit math is *that* slow.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 10, 2018 at 11:47 PM, James Y Knight via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Btrfs stores 64-bit sec, and 32-bit nsec on disk, and you can set and get it fine on linux. <span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I think it'd be a very bad idea to use a return type which must truncate the timestamp info from the filesystem.</span></div><div><br>Demo (on a btrfs partition):</div><div>$ touch -d '9000-04-21 09:45:12.123456789' asdf</div><div>$ ls -l --time-style=full-iso</div><div>-rw-r--r-- 1 jyknight users 0 9000-04-21 09:45:12.123456789 -0400 asdf</div><div><br></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">If the efficiency of 128-bit math was a concern, a different API for std::filesystem should've been used, with separate sec/nsec fields. But, seems too late for that now.</span></div><div><br></div><div>In fact, I now have the precise _opposite_ concern of Howard: I'm concerned that on 32-bit systems, libc++'s std::filesystem only uses a 64-bit type ("long long") for its timestamps, and _NOT_ the >=94-bit type which is required for correctness.</div><div><br></div><div>(Note that many 32-bit platforms are already using a 64-bit time_t, and others like Linux/i386 are in the midst of planning and executing on that transition -- being 32-bit is no excuse for being wrong.)</div><div><br></div><div>Since AFAIK no compilers support __int128 on 32-bit platforms, I suppose a custom class will need to be used, like <<a href="https://github.com/abseil/abseil-cpp/blob/master/absl/numeric/int128.h" target="_blank">https://github.com/abseil/<wbr>abseil-cpp/blob/master/absl/<wbr>numeric/int128.h</a>>...</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Fri, Aug 10, 2018 at 10:41 PM Howard Hinnant via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">On Aug 10, 2018, at 9:35 PM, Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>> wrote:<br>
> <br>
> Part of me is still concerned with the future, and the filesystems which are yet to exist.<br>
> <br>
<br>
Me too. But it is best to target modern systems when targeting future systems adds an unnecessary cost. When future systems come into being, it is likely because future hardware is making those future systems practical.<br>
<br>
E.g. nanosecond precision file systems were not produced prior to the widespread adoption of 64 bit hardware. Mainly because they were just too expensive on 32 bit hardware.<br>
<br>
In the future, we will have a better shot at dealing with that future. The std::lib we write today will have to evolve, no matter what we do today. Future proof where it is practical to do so, and don’t where it isn’t.<br>
<br>
Howard<br>
<br></div></div><span class="">
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</span></blockquote></div>
<br>______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>