This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.
Section: 184.108.40.206 [fs.op.resize_file] Status: WP Submitter: Richard Smith Opened: 2016-11-07 Last modified: 2018-03-24
View all issues with WP status.
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.
[Issues Telecon 16-Dec-2016]
[2018-01-16, Jonathan provides wording]
[2018-1-26 issues processing telecon]
Status to 'Tentatively Ready'
[2018-3-17 Adopted in Jacksonville]
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 (220.127.116.11 [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 18.104.22.168 [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 27.11.6 [fs.err.report].
Postconditions: file_size(p) == new_size. -3- Remarks: Achieves its postconditions as if by POSIX truncate().