[llvm-bugs] [Bug 35780] New: std::experimental::filesystem::remove() reports error instead of returning false if path does not exist

via llvm-bugs llvm-bugs at lists.llvm.org
Sat Dec 30 11:04:31 PST 2017


https://bugs.llvm.org/show_bug.cgi?id=35780

            Bug ID: 35780
           Summary: std::experimental::filesystem::remove() reports error
                    instead of returning false if path does not exist
           Product: libc++
           Version: 5.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: andrewgunnerson at gmail.com
                CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com

The C++17 standard requires that filesystem::remove() returns false if the
given path does not exist ([fs.op.remove]), but the current implementation will
always report an error if the POSIX remove() function returns -1.
https://github.com/llvm-mirror/libcxx/blob/05e705f9ecc348e42a710325743dd3bccbc89569/src/experimental/filesystem/operations.cpp#L662-L669

I think this could be fixed by reporting an error only if POSIX remove()
returns -1 and errno != ENOENT.

Test case:

    #include <experimental/filesystem>
    #include <iostream>

    namespace fs = std::experimental::filesystem;

    int main(int argc, char *argv[])
    {
        std::cout << "Deleted: " << fs::remove(argv[1]) << '\n';
    }

Output:

    $ LD_LIBRARY_PATH=/stuff/svn/llvm/build/lib ./a.out /tmp/non-existent-path
    terminating with uncaught exception of type
std::experimental::filesystem::v1::filesystem_error:
std::experimental::filesystem::remove: No such file or directory
    [1]    12425 abort (core dumped)  LD_LIBRARY_PATH=/stuff/svn/llvm/build/lib
./a.out /tmp/non-existent-path

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171230/7d9cb070/attachment.html>


More information about the llvm-bugs mailing list