From 0fbc3c0c84982bfa851e80cde02fa037c0f5eaa0 Mon Sep 17 00:00:00 2001 From: Jeff Epler Date: Sat, 12 Aug 2017 14:18:51 -0500 Subject: [PATCH] Fix build error with g++ 6.3 (Debian Stretch) On this platform, TEST_NULLPTR fails, even though nullptr and nullptr_t are supported: /home/jepler/src/stepcode/build/CMakeFiles/CMakeTmp/src.cxx:4:23: error: converting to 'bool' from 'std::nullptr_t' requires direct-initialization [-fpermissive] int main() {return !!f();} ~^~ Subsequent to this failure, the workaround definitions in sc_nullptr.h prevent standard C++ headers (which must refer to real nullptr) to fail. The failure occurs because the C++ standard apparently does not state that operator! may be used on nullptr. Despite this, some compilers have historically allowed it. g++ 6.3's behavior appears to be aligned with the standard. As requested by @brlcad, ensure that the function 'f' is used from main, to avoid a clever (but not nullptr-supporting) compiler from somehow skipping 'f' altogether, creating a false positive for nullptr support. --- cmake/SC_Config_Headers.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmake/SC_Config_Headers.cmake b/cmake/SC_Config_Headers.cmake index 2ed3ba6e..f272c94d 100644 --- a/cmake/SC_Config_Headers.cmake +++ b/cmake/SC_Config_Headers.cmake @@ -80,7 +80,7 @@ std::cout << \"1s is \"<< std::chrono::duration_cast( set( TEST_NULLPTR " #include std::nullptr_t f() {return nullptr;} -int main() {return !!f();} +int main() {return !(f() == f());} " ) cmake_push_check_state() if( UNIX )