kernel: assert invalid buffer preconditions in `btck_*_create` functions #35312

pull stringintech wants to merge 1 commits into bitcoin:master from stringintech:2026/05/kernel-assert-buffer-preconditions changing 1 files +4 −12

stringintech commented at 6:38 AM on May 18, 2026: contributor

The kernel API appears to use nullptr returns to report failures that callers may reasonably want to recover from: malformed serialized input, object construction failures, chainstate/load failures, and similar runtime conditions.

The raw create-function buffer checks seem to be a different case. A failure of ptr == nullptr && len > 0 does not indicate malformed input data or a failure encountered while decoding, deserializing, or constructing the requested object. Returning nullptr for these checks widens the recoverable error surface with cases that are better treated as programmer errors, similar to other asserted preconditions in this API such as invalid indices and impossible enum/flag states.

This change switches those buffer argument checks from nullptr returns to assertions in btck_transaction_create, btck_script_pubkey_create, btck_block_create, and btck_block_header_create. These functions still return nullptr when the provided bytes cannot be parsed or when object creation fails during processing.

I ended up looking at this while working on the kernel-bindings-tests spec/schema for btck_script_pubkey_create, where treating this path as a regular error did not seem like the right contract: https://github.com/stringintech/kernel-bindings-tests/pull/14#discussion_r3240859568.

kernel: assert invalid buffer preconditions in `btck_*_create` functions

Switch buffer `ptr == nullptr && len > 0` checks from `nullptr` returns to assertions in `btck_transaction_create`, `btck_script_pubkey_create`, `btck_block_create`, and `btck_block_header_create`. These checks represent invalid caller preconditions, not failures encountered while decoding, deserializing, or constructing the requested object.

4c6d65317e

DrahtBot added the label Validation on May 18, 2026
DrahtBot commented at 6:38 AM on May 18, 2026: contributor



The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.



Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35312.



Reviews

See the guideline for information on the review process.

Type Reviewers

Approach ACK stickies-v

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.

Type	Reviewers
Approach ACK	stickies-v

in src/kernel/bitcoinkernel.cpp:1378 in 4c6d65317e

1374 | @@ -1381,9 +1375,7 @@ int btck_chain_contains(const btck_Chain* chain, const btck_BlockTreeEntry* entr
1375 |  
1376 |  btck_BlockHeader* btck_block_header_create(const void* raw_block_header, size_t raw_block_header_len)
1377 |  {
1378 | -    if (raw_block_header == nullptr && raw_block_header_len != 0) {
1379 | -        return nullptr;
1380 | -    }
1381 | +    assert(raw_block_header != nullptr || raw_block_header_len == 0);

stickies-v commented at 4:09 PM on May 18, 2026:

As you highlighted elsewhere, since the interface states we require non-null and len 80, I think it makes sense to assert that here too (and with BITCOINKERNEL_ARG_NONNULL)? In my view this is orthogonal to the changes done in #33853, where empty spans are allowed.

stickies-v commented at 4:10 PM on May 18, 2026: contributor

Approach ACK

Contributors

Labels

kernel: assert invalid buffer preconditions in `btck_*_create` functions #35312

Code Coverage & Benchmarks

Reviews