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

[James Y Knight via cfe-dev]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180810/6c625b2f/attachment.html>