-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Open
Labels
Description
Describe the bug
I was investigating a libcxx failure on test std\input.output\filesystems\fs.op.funcs\fs.op.absolute\absolute.pass.cpp.
It fails because of a dubious test case that involves calling fs::absolute("", ec).
Interestingly, libstdc++, libc++, and MSVC STL all handle this differently.
Code
https://godbolt.org/z/MK97zP3jT
#include <filesystem>
#include <iostream>
namespace fs = std::filesystem;
int main()
{
const fs::path cwd = fs::current_path();
std::error_code ec{};
std::cout << "CWD is " << cwd << std::endl;
const fs::path ret = fs::absolute("", ec);
std::cout << ret << '\t' << ec << std::endl;
}Output
ret |
ec |
|
|---|---|---|
| libstdc++ | "" |
generic:22 |
| libc++ | cwd / |
system:0 |
| MSVC STL | "" |
system:0 |
Command-line test case
See Godbolt link.
Expected behavior
- I think that returning an empty
path()is fine; it's probably the desired behavior, unlike libc++.- However, since it's an 'erroneous' case, we may consider changing the implementation such that
ecis set with an appropriate error code.
- However, since it's an 'erroneous' case, we may consider changing the implementation such that
- If no implementation change is made, it should suffice to just document the reason of the test failure and move on.
STL version
Microsoft (R) C/C++ Optimizing Compiler Version 19.50.35725 for x64
Additional context
Reactions are currently unavailable