Maybe we should use SECP256K1_WARN_UNUSED_RESULT also internally. Currently we only have this in public API functions.
Originally posted by @real-or-random in #1867#pullrequestreview-4466893763
Use `SECP256K1_WARN_UNUSED_RESULT` internally #1872
issue real-or-random opened this issue on June 16, 2026-
real-or-random commented at 6:28 AM on June 16, 2026: contributor
- real-or-random added the label assurance on Jun 16, 2026
- real-or-random added the label tweak/refactor on Jun 16, 2026
- real-or-random added the label meta/development on Jun 16, 2026
-
real-or-random commented at 5:12 AM on June 19, 2026: contributor
I think #1876 somewhat misguided because it adds the warning to almost every function, but it exposes an interesting observation: We have some internal functions which always return 1, e.g.,
secp256k1_load_pubkey. These should probably returnvoidinstead.(For API functions, we tend to prefer returning an int, even if it's always 1. I'm not entire sure what the reason is. My best guess is that the idea is that these can be changed to return 0 in some cases without breaking the API. But if that's the reason, then it's a bit questionable because it's still a "semantic" break of the API: Callers who didn't check the return value of a function in libsecp256k1 0.x because it was documented to be always 1 have a high change of missing that that function can now return 0 in 0.x+1. Anyway, that's not the topic of this issue.)