#26022 Add util::ResultPtr class
https://github.com/bitcoin/bitcoin/pull/26022 · · +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
- 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.