[cfe-dev] Filesystem has Landed in Libc++

[John Sully via cfe-dev]

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.

On Fri, Aug 10, 2018 at 11:47 PM, James Y Knight via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Btrfs stores 64-bit sec, and 32-bit nsec on disk, and you can set and get
> it fine on linux. I think it'd be a very bad idea to use a return type
> which must truncate the timestamp info from the filesystem.
>
> Demo (on a btrfs partition):
> $ touch -d '9000-04-21 09:45:12.123456789' asdf
> $ ls -l --time-style=full-iso
> -rw-r--r-- 1 jyknight users   0 9000-04-21 09:45:12.123456789 -0400 asdf
>
> 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.
>
> 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.
>
> (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.)
>
> Since AFAIK no compilers support __int128 on 32-bit platforms, I suppose a
> custom class will need to be used, like <https://github.com/abseil/
> abseil-cpp/blob/master/absl/numeric/int128.h>...
>
>
>
>
> On Fri, Aug 10, 2018 at 10:41 PM Howard Hinnant via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Aug 10, 2018, at 9:35 PM, Eric Fiselier <eric at efcs.ca> wrote:
>> >
>> > Part of me is still concerned with the future, and the filesystems
>> which are yet to exist.
>> >
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Howard
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180811/3b1c805a/attachment.html>