777 | @@ -769,7 +778,7 @@ BITCOINKERNEL_API btck_ScriptPubkey* BITCOINKERNEL_WARN_UNUSED_RESULT btck_scrip
778 | * @param[out] status Nullable, will be set to an error code if the operation fails, or OK otherwise.
779 | * @return 1 if the script is valid, 0 otherwise.
780 | */
781 | -BITCOINKERNEL_API int BITCOINKERNEL_WARN_UNUSED_RESULT btck_script_pubkey_verify(
782 | +BITCOINKERNEL_API int btck_script_pubkey_verify(
Unlike plain predicates, the result here comes in two parts: status == OK does not imply script validity, and the return value still carries the actual valid/invalid result. Also this seems different from btck_transaction_check() and btck_block_check(), where the full outcome can be deduced from the validation state, so maybe keeping BITCOINKERNEL_WARN_UNUSED_RESULT here could help discourage callers from relying solely on the status out-param?
This one is a bit of an odd one out. But I agree that the btck_script_pubkey_verify function signature is a bit confusing to use, and the annotation might help to prevent wrong usage (until ideally, we eventually clean up the function signature). So I've reverted this change. Thanks!