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

[James Y Knight via llvm-dev]

Sure. However, it's not only btrfs, that's just one example.

Take macOS again: although the default filesystem (APFS) only stores a
64-bit value containing nanoseconds since Jan 1, 1970 on disk, that's just
one filesystem, not a fundamental restriction. The kernel and userspace
file APIs pass times through with the full 64-bit time_t range. (This can
be easily demonstrated with a FUSE filesystem.)

IMO, the set of platforms where a 64-bit value is likely to be
always-sufficient is probably just Windows -- there, the file APIs
themselves restrict the number of bits required (representing time as an
unsigned 64-bit quantity containing 100-nanosecond intervals since January
1, 1601), rather than just a particular filesystem's on-disk-storage method.

On Sat, Aug 11, 2018 at 11:08 AM Howard Hinnant <howard.hinnant at gmail.com>
wrote:

> On Aug 10, 2018, at 11:47 PM, James Y Knight <jyknight at google.com> wrote:
> >
> > Btrfs stores 64-bit sec, and 32-bit nsec on disk, and you can set and
> get it fine on linux.
>
> A 128 bit time_point seems like a good way to model those platforms that
> can mount Btrfs.  A 128 bit time_point does not seem like a good way to
> model those platforms which can only support 64 bit time stamps.
>
> The authors of a std::lib should write non-portable code so that I don’t
> have to.
>
> Howard
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180811/70c70de9/attachment.html>