Created on 2016-11-07.00:00:00 last changed 32 months ago
This wording is relative to N4713.
[Drafting note: I considered a slightly more verbose form: "Causes the size in bytes of the file p resolves to, as determined by file_size ([fs.op.file_size]), to be equal to new_size, as if by POSIX truncate." but I don't think it's an improvement. The intent of the proposed wording is that if either file_size(p) or truncate(p.c_str()) would fail then an error occurs, but no call to file_size is required, and file system races might change the size before any such call does occur.]
Modify [fs.op.resize_file] as indicated:
void resize_file(const path& p, uintmax_t new_size); void resize_file(const path& p, uintmax_t new_size, error_code& ec) noexcept;
-1--2- Throws: As specified in [fs.err.report].
Postconditions: file_size(p) == new_size. -3- Remarks: Achieves its postconditions as if by POSIX truncate().
[ 2018-3-17 Adopted in Jacksonville ]
[ 2018-1-26 issues processing telecon ]
Status to 'Tentatively Ready'
[ 2018-01-16, Jonathan provides wording ]
[ Issues Telecon 16-Dec-2016 ]
resize_file has this postcondition (after resolving late comment 42, see P0489R0):
Postcondition: file_size(p) == new_size.
This is impossible for an implementation to satisfy, due to the possibility of file system races. This is not actually a postcondition; rather, it is an effect that need no longer hold when the function returns.
|2018-03-18 16:03:30||admin||set||messages: + msg9725|
|2018-03-18 16:03:30||admin||set||status: voting -> wp|
|2018-02-12 01:13:49||admin||set||status: ready -> voting|
|2018-01-28 19:43:07||admin||set||messages: + msg9649|
|2018-01-28 19:43:07||admin||set||status: new -> ready|
|2018-01-20 15:28:42||admin||set||messages: + msg9612|
|2018-01-20 15:28:42||admin||set||messages: + msg9611|
|2016-12-16 20:56:38||admin||set||messages: + msg8747|