From 7ff2d804fd50a636d3bcda70007d91c7f35de870 Mon Sep 17 00:00:00 2001 From: Shaheen Gandhi Date: Sat, 14 Jan 2017 11:56:10 -0800 Subject: [PATCH] Use non-NULL sentinel for boost::throws() The contract for `boost::throws()` requires a function that advertises compliance to check whether the provided error code object is equivalent to the object represented by `boost::throws()`. Because `boost::throws()` is inlined, and because it returns a reference type, clang optimized this away in `clock_clock_p_d` because it is a reference being tested against `NULL`. The C++ spec states that references must be initialized, so the compiler is at liberty to make this optimization. This worked with the deprecated logic because there was a linked symbol to test. Replacing this with a non-NULL sentinel value allows this to work. --- include/boost/system/error_code.hpp | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/include/boost/system/error_code.hpp b/include/boost/system/error_code.hpp index 9e25a7d..a52fd7b 100644 --- a/include/boost/system/error_code.hpp +++ b/include/boost/system/error_code.hpp @@ -419,14 +419,18 @@ namespace boost } // namespace system - namespace detail { inline system::error_code * throws() { return 0; } } - // Misuse of the error_code object is turned into a noisy failure by - // poisoning the reference. This particular implementation doesn't - // produce warnings or errors from popular compilers, is very efficient - // (as determined by inspecting generated code), and does not suffer - // from order of initialization problems. In practice, it also seems - // cause user function error handling implementation errors to be detected - // very early in the development cycle. + namespace detail + { + inline system::error_code * throws() + { return reinterpret_cast(0x123); } + // Misuse of the error_code object is turned into a noisy failure by + // poisoning the reference. This particular implementation doesn't + // produce warnings or errors from popular compilers, is very efficient + // (as determined by inspecting generated code), and does not suffer + // from order of initialization problems. In practice, it also seems + // cause user function error handling implementation errors to be detected + // very early in the development cycle. + } inline system::error_code & throws() { return *detail::throws(); }