Created on 2017-12-06.00:00:00 last changed 31 months ago
This wording is relative to N4713.
Replace [fs.filesystem_error.members] p2-4, including Tables 119 through 121, with the following:
filesystem_error(const string& what_arg, error_code ec);
-2- Postconditions: code() == ec, path1().empty() == true, path2().empty() == true, and string_view(what()).find(what_arg) != string_view::npos.
filesystem_error(const string& what_arg, const path& p1, error_code ec);
-3- Postconditions: code() == ec, path1() returns a reference to the stored copy of p1, path2().empty() == true, and string_view(what()).find(what_arg) != string_view::npos.
filesystem_error(const string& what_arg, const path& p1, const path& p2, error_code ec);
-4- Postconditions: code() == ec, path1() returns a reference to the stored copy of p1, path2() returns a reference to the stored copy of p2, and string_view(what()).find(what_arg) != string_view::npos.
Edit [fs.filesystem_error.members] p7 as indicated:
const char* what() const noexcept override;
A string containing runtime_error::what().The exact format is unspecified. Implementations should include the system_error::what() string and the pathnames of path1 and path2 in the native format in the returned string.
[ 2018-3-17 Adopted in Jacksonville ]
[ 2018-01-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]
[fs.filesystem_error.members] says that constructors of filesystem_error have the postcondition that runtime_error::what() has the value what_arg.c_str(). That's obviously incorrect: these are pointers to distinct copies of the string in any sane implementation and cannot possibly compare equal.The requirement seems suspect for a further reason: it mandates the content of the string returned by runtime_error::what(), but filesystem_error has no direct control over the construction of its indirect non-virtual base class runtime_error. Instead, what is passed to runtime_error's constructor is determined by system_error's constructor, which in many implementations is an eagerly crafted error string. This is permitted by the specification of system_error (see [syserr.syserr]) but would make the requirement unimplementable. The proposed wording below adjusts the postcondition using the formula of system_error's constructor. As an editorial change, it also replaces the postcondition tables with normal postcondition clauses, in the spirit of editorial issue 1875.
|2021-02-25 10:48:01||admin||set||status: wp -> c++20|
|2018-03-18 16:03:30||admin||set||messages: + msg9752|
|2018-03-18 16:03:30||admin||set||status: voting -> wp|
|2018-02-12 01:13:49||admin||set||status: ready -> voting|
|2018-01-14 20:16:01||admin||set||messages: + msg9608|
|2018-01-14 20:16:01||admin||set||status: new -> ready|
|2017-12-08 20:36:16||admin||set||messages: + msg9583|