In file included from src/bddsolve.cpp:30: include/sat/reach.h:25:10: error: no viable conversion from returned value of type 'std::ifstream' (aka 'basic_ifstream<char>') to function return type 'bool' return (from); ^~~~~~ build log: http://sprunge.us/TSfH regressed by: https://github.com/llvm-mirror/libcxx/commit/3a1b90a866b6
(In reply to Dimitry Andric from bug 216034 comment #6) > Note that the upstream author has reverted the commit causing this here: > > http://llvm.org/viewvc/llvm-project?rev=291921&view=rev > > and has also merged it to the 4.0 branch. I will import the upstream > branch into the projects/clang400-import branch soon. lang/gcc6 and later versions are also affected. In file included from src/bddsolve.cpp:30:0: include/sat/reach.h: In function 'bool exists_file(const string&)': include/sat/reach.h:25:15: error: cannot convert 'std::ifstream {aka std::basic_ifstream<char>}' to 'bool' in return return (from); ^
Created attachment 178901 [details] Patch to fix the build Hi there, Thanks for the report. So if I understand the issue correctly: C++ iostreams have two type conversion operators: - One that returns a true/false value in the form of a pointer, - As of C++11, one that uses a 'bool' instead. I guess the bddsolve code was written with the first in mind. Now the second flavour appears, but that one has the 'explicit' keyword, meaning we now need to cast to 'bool' explicitly. Instead of going through the hassle of casting, the attached patch changes the code to use the fail() member function. Does that look like the right way of solving this? If so, I'll send a patch to this program's author. Best regards, Ed
> bool exists_file(const std::string& filename) > { > std::ifstream from(filename.c_str()); > - return (from); > + return !from.fail(); Why not "return from.good()" instead similar to textproc/libxml++26 upstream fix? Otherwise, ask toolchain@ whether to convert or not. I don't know much C++.
Because the good() member function isn't the exact opposite of the fail() member function. See the table at the bottom of this page: http://en.cppreference.com/w/cpp/io/basic_ios/fail Changing it to use good() alters the code's behaviour.
So to get this straight: this no longer breaks, right? It was caused by a change to libc++, but that change has been reverted. If so, shall I mark this bug as WONTFIX?
DragonFly, architectures on external toolchain and users that prefer GCC may be affected after upgrading GCC to 6.x or later. For some reason Clang (even 4.0) is still stuck with C++98 by default, so such errors can be fixed by sprinkling USE_CXXSTD=gnu++98 in ports. https://gcc.gnu.org/gcc-6/porting_to.html
Clang 6 defaults to C++14, so pkg-fallout@ will complain soon.
A commit references this bug: Author: ed Date: Wed Jan 17 14:28:32 UTC 2018 New revision: 459258 URL: https://svnweb.freebsd.org/changeset/ports/459258 Log: Upgrade bddsolve to version 1.04. This release includes a fix that should make it build with C++14. PR: 216080 Reviewed by: jbeich Differential Revision: https://reviews.freebsd.org/D13951 Changes: head/science/bddsolve/Makefile head/science/bddsolve/distinfo