[Bug libstdc++/71415] New: std::filesystem::exists that does not throw sets error code if file does not exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71415
Bug ID: 71415
Summary: std::filesystem::exists that does not throw sets error
code if file does not exist
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: marejde at gmail dot com
Target Milestone: ---
The following program:
#include
#include
int main(int argc, char *argv[])
{
std::error_code error_code;
bool exists = std::experimental::filesystem::exists("does_not_exist",
error_code);
std::cout << "exists: " << exists << '\n';
std::cout << "error_code.value(): " << error_code.value() << '\n';
std::cout << "error_code.message(): " << error_code.message() << '\n';
std::cout << "error_code operator bool: " << (error_code.value() ? true
: false) << '\n';
return 0;
}
outputs:
exists: 0
error_code.value(): 2
error_code.message(): No such file or directory
error_code operator bool: 1
Which means it is not possible to discern between an error and when the file
does not exist without examining error_code.value(), which is platform
dependent.
Tested on Arch Linux with "gcc (GCC) 6.1.1 20160501".
[Bug libstdc++/71415] std::filesystem::exists that does not throw sets error code if file does not exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71415 --- Comment #1 from Martin Ejdestig --- Sorry, a copy paste error slipped in. Last print out should be: std::cout << "error_code operator bool: " << (error_code ? true : false) << '\n'; Output is still the same though.
[Bug libstdc++/71415] std::filesystem::exists that does not throw sets error code if file does not exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71415 --- Comment #3 from Martin Ejdestig --- > The semantics of exists(const path&, error_code&) are precisely specified, > and > I think this behaviour is correct according to the specification. This > is also > consistent with Boost.Filesystem. Oh, OK. It seems odd to me that an error is signaled for something that should be considered "normal operations" though. > I'll discuss with the C++ committee whether this behaviour is really > desirable, > but it seems to be what the spec requires, and not a bug in GCC. OK, thanks. Is there some way for me to track the discussion? The isocpp.org Google group? Or is there e.g. some other mailing list where std::filesystem is discussed? I am just curious. :)
[Bug libstdc++/71415] std::filesystem::exists that does not throw sets error code if file does not exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71415 --- Comment #5 from Martin Ejdestig --- (In reply to Jonathan Wakely from comment #4) > A new issue should get added to > http://cplusplus.github.io/LWG/lwg-active.html Thank you.
[Bug libstdc++/78237] New: std::timed_mutex::try_lock_for/until affected by system realtime clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78237
Bug ID: 78237
Summary: std::timed_mutex::try_lock_for/until affected by
system realtime clock
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: marejde at gmail dot com
Target Milestone: ---
The following program:
#include
#include
#include
#include
int main(void)
{
std::recursive_timed_mutex mutex;
bool ret = mutex.try_lock_for(std::chrono::seconds(2));
std::cout << "ret = " << ret << "\n";
std::thread thread([&mutex]() {
std::this_thread::sleep_for(std::chrono::seconds(1));
auto now = std::chrono::steady_clock::now();
bool ret = mutex.try_lock_until(now +
std::chrono::seconds(60));
std::cout << "ret = " << ret << "\n";
});
thread.join();
return 0;
}
does not work as expected when modifying the system time. try_lock_until()
returns false immediately when time is advanced passed now + 60s.
Compiling with Clang and libc++ try_lock_until() waits for 60 seconds
regardless of what the system time is changed to.
Looking at the implementation in libstdc++ it looks like it ends up calling
pthread_mutex_timedwait() (that uses CLOCK_REALTIME) while the libc++
implementation implements the methods with a condition variable.
[Bug libstdc++/65499] New: Missing "using namespace literals::chrono_literals" in std::chrono
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65499
Bug ID: 65499
Summary: Missing "using namespace literals::chrono_literals" in
std::chrono
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: marejde at gmail dot com
Reading http://en.cppreference.com/w/cpp/chrono/operator%22%22min (sorry, I do
not have the spec readily available) it says:
"In addition, within the namespace std::chrono, the directive using namespace
literals::chrono_literals; is provided by the standard library, so that if a
programmer uses using namespace std::chrono; to gain access to the duration
classes, the duration literal operators become visible as well."
The following program:
#include
#include
int main(void)
{
using namespace std::chrono;
minutes min = 36min;
return 0;
}
Does not compile with GCC 4.9.2 while it does with Clang 3.6.
Looking at GCC trunk as of today I do not see a "using namespace
literals::chrono_literals;" anywhere in libstdc++-v3/include/ . Clang's libc++
has it in the chrono namespace though.
Would be great if this could be fixed before GCC 5.0 is released so I don't
have to sprinkle "using namespace literals::chrono_literals;" in my code to be
able to compile with GCC.
[Bug libstdc++/65499] Missing "using namespace literals::chrono_literals" in std::chrono
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65499
--- Comment #1 from Martin Ejdestig ---
See the end of 20.12.2 ("Header synopsis").
Maybe it is too late for 5.0?
