How to CHECK_EQ against nullptr?

[Simon Que]

I have this line in my code:

  CHECK_EQ(MallocHook::SetNewHook(&NewHook), nullptr);

MallocHook::SetNewHook returns a pointer. I want to make sure it is null.

The above check passes on Release build but fails on Debug build:

../../base/logging.h: In instantiation of 'std::string* logging::MakeCheckOpString(const t1&, const t2&, const char*) [with t1 = void (*)(const void*, long unsigned int); t2 = std::nullptr_t; std::string = std::basic_string<char>]':
../../base/logging.h:540:1:   required from 'std::string* logging::CheckEQImpl(const t1&, const t2&, const char*) [with t1 = void (*)(const void*, long unsigned int); t2 = std::nullptr_t; std::string = std::basic_string<char>]'
../../components/metrics/leak_detector/leak_detector.cc:239:3:   required from here
../../base/logging.h:503:40: error: ambiguous overload for 'operator<<' (operand types are 'std::basic_ostream<char>' and 'std::nullptr_t')
   ss << names << " (" << v1 << " vs. " << v2 << ")";
                                        ^

I searched through the Chrome code but couldn't find any other examples where nullptr was used in CHECK_EQ.

I suppose I could revise that line to:

  CHECK(!MallocHook::SetNewHook(&NewHook))

But I'm wondering if there's an actual way to do a nullptr CHECK_EQ like that.

Simon

[Scott Hess]

A common approach to this kind of problem would be:

  CHECK(MallocHook::SetNewHook(&NewHook) == nullptr);

which has plenty of examples in the codebase (and the != version also).

In this case, there's not really anything useful that the logging will print, since nullptr is obviously going to be a constant, and the pointer value probably won't be helpful to know.

-scott

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Rouslan Solomakhin]

An ugly way that should work:

CHECK_EQ(static_cast<NewHook>(nullptr), MallocHook::SetNewHook(&NewHook));

By the way, error messages usually print "Expected <first param>, but got <second param>," so the first param should be the expected value.

[Mark Mentovai]

Rouslan Solomakhin wrote:

An ugly way that should work:

CHECK_EQ(static_cast<NewHook>(nullptr), MallocHook::SetNewHook(&NewHook));

By the way, error messages usually print "Expected <first param>, but got <second param>," so the first param should be the expected value.

That’s true of gtest’s EXPECT_EQ() and ASSERT_EQ(), but not of logging.h’s CHECK_EQ() or DCHECK_EQ().

[Peter Kasting]

This is true.  That said, I usually suggest in reviews that people stick with (expected, actual) for all EQ and NE comparisons just to be in a consistent habit and not risk accidentally getting this wrong.

PK