Add ARG_CHECKs to ensure "array of pointers" elements are non-NULL #1779
+16
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We currently have five public API functions that take an "array of pointers" as input parameter:
secp256k1_ec_pubkey_combine(ins: array of pointers to public keys to add)secp256k1_ec_pubkey_sort(pubkeys: array of pointers to public keys to sort)secp256k1_musig_pubkey_agg(pubkeys: array of pointers to public keys to aggregate)secp256k1_musig_nonce_agg(pubnonces: array of pointers to public nonces to aggregate)secp256k1_musig_partial_sig_agg(partial_sigs: array of pointers to partial signatures to aggregate)Out of these, only
_ec_pubkey_combineverifies that the individual pointer elements in the array are non-NULL each:secp256k1/src/secp256k1.c
Lines 774 to 775 in e7f7083
This PR adds corresponding
ARG_CHECKSfor the other API functions as well, in order to avoid running into potential UB due to NULL pointer dereference. It seems to me that the tiny run-time overhead is worth it doing this for consistency and to help users in case the arrays are set up incorrectly (I'm thinking e.g. of language binding writers where getting this right might be a bit more involved).Looking into this was motivated by a review of furszy (thanks!), who pointed out that the non-NULL checks are missing in at least one API function in the silentpayments module PR as well. Happy to add some
CHECK_ILLEGALtests if there is conceptual support for this PR.