Section: 15.25 [filesys.ts::fs.op.last_write_time] Status: TS Submitter: P.J. Plauger Opened: 2014-01-30 Last modified: 2017-07-30 20:10:41 UTC
Priority: Not Prioritized
View all other issues in [filesys.ts::fs.op.last_write_time].
View all issues with TS status.
In last_write_time, static_cast<file_time_type>(-1) is ill formed, (possibly should be chrono<unspecified-trivial-clock>::from_time_t(-1)).
[2014-02-08 Daniel comments and provides wording]
I agree that the current wording needs to be fixed, but it is unclear to me whether invoking from_time_t (which is only guaranteed to exist for std::chrono::system_clock) with a value of time_t(-1) is a well-defined operation. Reason is that the C Standard makes a difference between a calendar time and the value time_t(-1) as an error indication. But the specification of system_clock::from_time_t only says "A time_point object that represents the same point in time as t […]" and it is not clear whether time_t(-1) can be considered as a "point in time". Instead of relying on such a potentially subtle semantics of the conversion result of time_t(-1) to std::chrono::system_clock::time_point with a further conversion to file_time_type (which in theory could led to overflow or underflow and thus another potential source of undefined behaviour), I suggest to change the current error value of last_write_time to one of the well-define limiting values of file_time_type, e.g. file_time_type::min().
[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]
This wording is relative to SG3 working draft.
Change the last write time prototype specification, 15.25 [fs.op.last_write_time], as indicated:
file_time_type last_write_time(const path& p); file_time_type last_write_time(const path& p, error_code& ec) noexcept;
Returns: The time of last data modification of p, determined as if by the value of the POSIX stat structure member st_mtime obtained as if by POSIX stat(). The signature with argument ec returns
static_cast<file_time_type>(-1)if an error occurs.