Clarification on CHECK() guidance for pointer dereferences (and history of style guide change)

[Tommy Nyquist]

Hi C++ experts!

I'm looking for some historical context and current guidance regarding a change to the C++ style guide from early 2023 (sorry, I know I’m way late in actually asking someone about this).

https://crrev.com/c/4287020 removed a section that explicitly advised against using CHECK() to guard pointer dereferences:

"Dereferencing a null pointer in C++ is generally UB (undefined behavior) as the compiler is free to assume a dereference means the pointer is not null and may apply optimizations based on that. As such, there is sometimes a strong opinion to CHECK() pointers before dereference. Chromium builds with the no-delete-null-pointer-checks Clang/GCC flag which prevents such optimizations, meaning the side effect of a null dereference would just be the use of 0x0 which will lead to a crash on all the platforms Chromium supports. As such we do not use CHECK() to guard pointer deferences."

Since this text was removed but not really replaced with any conflicting guidance as far as I can tell, I am trying to figure out how we are expected to reason about this now.

So I guess my questions are:

(1) Do we still rely on no-delete-null-pointer-checks to ensure immediate crashes on null dereferences?

(2) Does removing this text imply a shift in policy? Should we now explicitly CHECK() before dereferencing (when validity is critical), or is the implicit crash still the preferred mechanism to avoid code bloat?

--
Tommy

[Kyle Charbonneau]

(1) Do we still rely on no-delete-null-pointer-checks to ensure immediate crashes on null dereferences?

We still add that compiler flag here. Note that something like the following might not crash even if foo is null. 

  auto* foo = GetPointer();
  foo->Bar(param); // maybe no crash

If Bar() is not virtual and the function doesn't read/write any member variables it's possible the null pointer isn't dereferenced. If Bar() can modify global state without dereferencing the this pointer, that might not be caught by no-delete-null-pointer-checks, so adding a CHECK could be useful.

  auto* foo = GetPointer();
  CHECK(foo);  // crash
  foo->Bar(param);

(2) Does removing this text imply a shift in policy? Should we now explicitly CHECK() before dereferencing (when validity is critical), or is the implicit crash still the preferred mechanism to avoid code bloat?

A previous thread discusses this topic that you might find useful.

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAA6XDjNrkvoL8iYGSOf8L0SqKhXMwY3zjDsYjvYFgWS7uW6d-w%40mail.gmail.com.

[Jeremy Roman]

On Tue, Jan 20, 2026 at 10:50 AM Kyle Charbonneau <kyle...@chromium.org> wrote:

(1) Do we still rely on no-delete-null-pointer-checks to ensure immediate crashes on null dereferences?

We still add that compiler flag here. Note that something like the following might not crash even if foo is null. 

  auto* foo = GetPointer();
  foo->Bar(param); // maybe no crash

If Bar() is not virtual and the function doesn't read/write any member variables it's possible the null pointer isn't dereferenced.

nit: I believe the dereference occurs (and therefore the program behavior is undefined) regardless -- it's just that, as you point out, it might not crash. (And technically, Bar could have been devirtualized through whole-program optimization, even if it was virtual in the program source, so it too might not crash but do something else in practice.)

Agreed in substance, though.

 

If Bar() can modify global state without dereferencing the this pointer, that might not be caught by no-delete-null-pointer-checks, so adding a CHECK could be useful.

  auto* foo = GetPointer();
  CHECK(foo);  // crash
  foo->Bar(param);

(2) Does removing this text imply a shift in policy? Should we now explicitly CHECK() before dereferencing (when validity is critical), or is the implicit crash still the preferred mechanism to avoid code bloat?

A previous thread discusses this topic that you might find useful.

On Fri, Jan 16, 2026 at 3:10 PM Tommy Nyquist <nyq...@chromium.org> wrote:

Hi C++ experts!

I'm looking for some historical context and current guidance regarding a change to the C++ style guide from early 2023 (sorry, I know I’m way late in actually asking someone about this).

https://crrev.com/c/4287020 removed a section that explicitly advised against using CHECK() to guard pointer dereferences:

"Dereferencing a null pointer in C++ is generally UB (undefined behavior) as the compiler is free to assume a dereference means the pointer is not null and may apply optimizations based on that. As such, there is sometimes a strong opinion to CHECK() pointers before dereference. Chromium builds with the no-delete-null-pointer-checks Clang/GCC flag which prevents such optimizations, meaning the side effect of a null dereference would just be the use of 0x0 which will lead to a crash on all the platforms Chromium supports. As such we do not use CHECK() to guard pointer deferences."

Since this text was removed but not really replaced with any conflicting guidance as far as I can tell, I am trying to figure out how we are expected to reason about this now.

So I guess my questions are:

(1) Do we still rely on no-delete-null-pointer-checks to ensure immediate crashes on null dereferences?

(2) Does removing this text imply a shift in policy? Should we now explicitly CHECK() before dereferencing (when validity is critical), or is the implicit crash still the preferred mechanism to avoid code bloat?

--
Tommy

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAA6XDjNrkvoL8iYGSOf8L0SqKhXMwY3zjDsYjvYFgWS7uW6d-w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAERSRDBavC3vC4JR7VNW-z2konScWg-7RM1vs12FqdPRo-V4iA%40mail.gmail.com.