Proposed resolution:

This wording is relative to N4713.

1. 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.

2. Edit [fs.filesystem_error.members] p7 as indicated:

   const char* what() const noexcept override;
   

   -7- Returns: A string containing runtime_error::what().An ntbs that incorporates the what_arg argument supplied to the constructor. 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.