This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.

2665. remove_filename() post condition is incorrect

Section: 31.12.6.5.5 [fs.path.modifiers] Status: Resolved Submitter: Eric Fiselier Opened: 2014-06-07 Last modified: 2017-07-17

Priority: 1

View all issues with Resolved status.

Discussion:

remove_filename() specifies !has_filename() as the post condition. This post condition is not correct. For example the path "/foo" has a filename of "foo". If we remove the filename we get "/", and "/" has a filename of "/".

[2014-06-08 Beman supplies an Effects: element.]

[2014-06-17 Rapperswil LWG will investigate issue at a subsequent meeting.]

[2016-04 Issue updated to address the C++ Working Paper. Previously addressed File System TS]

[2016-04, Issues Telecon]

There was concern that the effects wording is not right. Jonathan provided updated wording.

Previous resolution [SUPERSEDED]:

    path& remove_filename();
  

Postcondition: !has_filename().

Effects: *this = parent_path(), except that if parent_path() == root_path(), clear().

Returns: *this.

[Example:

        std::cout << path("/foo").remove_filename();  // outputs "/"
        std::cout << path("/").remove_filename();     // outputs ""
      

—end example]

[2016-08 Chicago]

Wed AM: Move to Tentatively Ready

Previous resolution [SUPERSEDED]:

  path& remove_filename();

Postcondition: !has_filename().

Effects: If *this == root_path(), then clear(). Otherwise, *this = parent_path().

Returns: *this.

[Example:

      std::cout << path("/foo").remove_filename();  // outputs "/"
      std::cout << path("/").remove_filename();     // outputs ""
    

—end example]

[2016-10-16, Eric reopens and provides improved wording]

The suggested PR is incorrect. root_path() removes redundant directory separators.

Therefore the condition *this == root_path() will fail for "//foo///" because root_path() returns "//foo/". However using path::compare instead would solve this problem.

[2016-11-21, Beman comments]

This issue is closely related to CD NB comments US 25, US 37, US 51, US 52, US 53, US 54, and US 60. The Filesystem SG in Issaquah recommended that these all be handled together, as they all revolve around the exact meaning of "filename" and path decomposition.

[2017-07-14, Davis Herring comments]

Changes in P0492R2 changed remove_filename() and has_filename() in such a fashion that the postcondition is now satisfied. (In the example in the issue description, "/foo" does gets mapped to "/", but path("/").has_filename() is false.)

[2017-07, Toronto Thursday night issues processing]

This was resolved by the adoption of P0492R2.

Proposed resolution:

This wording is relative to N4606.

1. Modify 31.12.6.5.5 [fs.path.modifiers] as indicated:

   path& remove_filename();
   

   -5- PostconditionEffects: !has_filename()If this->compare(root_path()) == 0, then clear(). Otherwise, *this = parent_path()..

   -6- Returns: *this.

   -7- [Example:

   std::cout << path("/foo").remove_filename(); // outputs "/"
   std::cout << path("/").remove_filename(); // outputs ""
   

   — end example]