#26022 Add util::ResultPtr class

full analysis

https://github.com/bitcoin/bitcoin/pull/26022 · ryanofsky · +813/-199 in 19 files, 11 commits · labels: none · draft

Goal

  • Make checking and accessing pointer results safer and less awkward for developers
  • Prevents accidental null pointer dereferences when a function returns a null pointer without an error

This pull request introduces `util::ResultPtr`, a wrapper template over `util::Result` tailored for pointer types such as `std::unique_ptr`. It enables single dereferencing (`*result`, `result->member`) instead of nested dereferencing (`**result`) and evaluates to false in boolean contexts if the contained pointer is null. It also updates several call sites in the network address manager and wallet loader interfaces to use the new wrapper.

Problem: Using `util::Result` with smart pointers is awkward and error-prone because callers must dereference twice to access pointee members. Additionally, checking a result in a boolean context evaluates to true if no error occurred even when the contained pointer is null, which can lead to unexpected null-pointer dereferences (issue #26004).

Category: Utilities (logging, arguments, libraries) (#42 of 66)

P3 · cleanup

  • P3 because it provides an ergonomic and safety improvement to shared result-handling utilities
  • Reduces syntax awkwardness and null-check bugs but is internal convenience that can wait

P3 because it offers a helpful ergonomic improvement to shared result-handling utilities. It addresses confusing syntax and null checks highlighted in issue #26004, but is internal convenience that can be deferred without project harm.

Membership: Defines util::ResultPtr in src/util/result.h to provide syntactic sugar and safer boolean semantics for pointer result types.

Factors: security/stability 0, bug 0, performance 0, user value 0, leverage 1

Reviewability: Ready: Review #25665 first

The PR is clean and tests pass, but it is stacked on top of open PR #25665.

Author status: active, periodically rebasing on base PR #25665

Open concerns:

  • l0rinc noted an apparently inverted boolean check in `src/wallet/interfaces.cpp` for `restoreWallet`.

Agreement: Mild

  • No overall reviews yet
  • Unaddressed question: possible inverted condition in wallet restore (l0rinc)

Mild: no high-level reviews yet, and l0rinc pointed out an inverted condition in wallet restore

Nobody has commented on the PR as a whole, and an open inline comment points out a potential logic bug in `restoreWallet`.

  • l0rinc noted on src/wallet/interfaces.cpp: 'isn\'t this inverted?'

Review verdicts (DrahtBot): 0

Dependencies

Depends on: #25665

Files

251 lines under test/bench/ci.

  • src/util/result.h +382/-63
  • src/test/result_tests.cpp +230/-11
  • src/node/chainstate.cpp +56/-39
  • src/util/messages.h +53/-0
  • src/init.cpp +22/-21
  • src/util/messages.cpp +30/-0
  • src/wallet/interfaces.cpp +9/-20
  • src/node/chainstate.h +6/-22
  • src/kernel/bitcoinkernel.cpp +7/-7
  • src/test/util/setup_common.cpp +4/-4
  • src/interfaces/wallet.h +3/-3
  • src/qt/walletcontroller.cpp +3/-3
  • src/wallet/wallet.cpp +2/-2
  • .github/workflows/ci.yml +1/-1
  • ci/test/00_setup_env_native_previous_releases.sh +1/-1
  • src/addrdb.cpp +1/-1
  • src/addrdb.h +1/-1
  • src/kernel/CMakeLists.txt +1/-0
  • src/util/CMakeLists.txt +1/-0

Card

PR #26022 introduces util::ResultPtr as a wrapper over util::Result to provide single-dereference syntax and safer boolean null checks when returning pointers. It addresses an awkward usability issue documented in #26004 by reducing boilerplate at call sites. The PR is stacked on top of open PR #25665 and remains in draft status. Review feedback is minimal so far, with an open inline note concerning an inverted condition in wallet restore.

Data

dossier JSON · extract JSON · model openrouter/google/gemini-3.8-flash, generated 2026-09-17T15:48, confidence high, input hash 02067a3888ad6437