Summary:
The ``file_time_type`` time point is used to represent the write times for files.
Its job is to act as part of a C++ wrapper for less ideal system interfaces. The
underlying filesystem uses the ``timespec`` struct for the same purpose.
However, the initial implementation of ``file_time_type`` could not represent
either the range or resolution of ``timespec``, making it unsuitable. Fixing
this requires an implementation which uses more than 64 bits to store the
time point.
I primarily considered two solutions: Using ``__int128_t`` and using a
arithmetic emulation of ``timespec``. Each has its pros and cons, and both
come with more than one complication.
However, after a lot of consideration, I decided on using `__int128_t`. This patch implements that change.
Please see the [FileTimeType Design Document](http://libcxx.llvm.org/docs/DesignDocs/FileTimeType.html) for more information.
Reviewers: mclow.lists, ldionne, joerg, arthur.j.odwyer, EricWF
Reviewed By: EricWF
Subscribers: christof, K-ballo, cfe-commits, BillyONeal
Differential Revision: https://reviews.llvm.org/D49774
llvm-svn: 337960
Use CLOCK_UPTIME_RAW in case clock_gettime is available on Darwin.
On Apple platforms only CLOCK_UPTIME_RAW or mach_absolute_time are able
to time functions in the nanosecond range. Thus, they are the only
acceptable implementations of steady_clock.
Differential Revision: https://reviews.llvm.org/D27429
rdar://problem/29449467
llvm-svn: 291466
Replace the use of _WIN32 in libc++. Replace most use with a C runtime
check _LIBCPP_MSVCRT or the new _LIBCPP_WIN32 to indicate that we are
using the Win32 API. Use a new _LIBCPP_WCHAR_IS_UCS2 to indicate that we
are on an environment that has a short wchar_t.
llvm-svn: 290910
As pointed out by Howard, this is actually 134774 days (* 24 * 3600),
and therefore seconds, not 100ns units. Adjust the units to reflect
reality.
llvm-svn: 290824
Drawing some inspiration from code from Bill O'Neal as pointed out by
Howard, rework the code to avoid an overflow in the duration. Adjust
the style to match libc++ style as well.
Create a local typedef for the FILETIME duration (100-ns units). Use
this to define the difference between the NT and the UNIX epochs (which
previously overflowed due to the representation limits due to the
bouncing to ns). Return the FILETIME duration biased by the NT-to-UNIX
epoch conversion.
Use of the custom duration makes it easier to read and reason about the
code.
llvm-svn: 290806
system_clock::now is not entirely straight forward on Windows, which
does not have a clock_gettime function.
GetSystemTimeAsFileTime gives us the value relative to the NT epoch (Jan
1 1601) rather than the Unix epoch (Jan 1 1970). However, this function
has a low resolution (~10ms). Newer versions of Windows provide
GetSystemTimePreciseAsFileTime which gives us a much more accurate time
(<1us). Unfortunately, the latter is only available on Windows 8+ when
targeting desktop apps.
llvm-svn: 290803
The function definitions being guarded by the pragma were all static, so
they wouldn't be exported anyway. In any case, we should prefer the
visibility macros. No functional change.
Differential Revision: https://reviews.llvm.org/D26940
llvm-svn: 287768
The system_clock::now() function currently uses gettimeofday(). The
problem with gettimeofday() is that it is an obsolete XSI function,
hence unavailable on CloudABI. See:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/gettimeofday.html
Change this code to use clock_gettime() with CLOCK_REALTIME instead,
which is more consistent, as clock_gettime() is already used for
steady_clock.
A previous version of this change actually attempted to change
system_clock::duration, but I reverted this part as it breaks the
existing ABI.
Differential Revision: http://reviews.llvm.org/D8253
Approved by: jroelofs
llvm-svn: 237390
