ci: Use clang-snapshot in "MSan" job

[hebasto]

In Bitcoin Core, the "MSan" CI jobs use the latest tagged Clang available from http://apt.llvm.org.

This PR applies similar changes and switches the "MSan" CI jobs to clang-snapshot.

This exposes problematic code that was reported in bitcoin/bitcoin#33284.

[hebasto]

From https://github.com/bitcoin-core/secp256k1/actions/runs/17829295048/job/50691626826:

   CC       src/noverify_tests-tests.o
src/tests.c:6051:34: error: variable 'pubkey' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
 6051 |     SECP256K1_CHECKMEM_UNDEFINE(&pubkey, sizeof(pubkey));
      |                                  ^~~~~~
1 error generated.

[hebasto]

From https://github.com/bitcoin-core/secp256k1/actions/runs/17829295048/job/50691626826:

   CC       src/noverify_tests-tests.o
src/tests.c:6051:34: error: variable 'pubkey' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
 6051 |     SECP256K1_CHECKMEM_UNDEFINE(&pubkey, sizeof(pubkey));
      |                                  ^~~~~~
1 error generated.

Added a commit to silence the -Wuninitialized-const-pointer warning.

[real-or-random]

I think that's a Clang bug.

SECP256K1_CHECKMEM_UNDEFINE expands to __msan_allocated_memory with signature:

/* Tell MSan about newly allocated memory (ex.: custom allocator).
   Memory will be marked uninitialized, with origin at the call site. */
void SANITIZER_CDECL __msan_allocated_memory(const volatile void *data,
                                             size_t size);

https://github.com/llvm/llvm-project/blob/24b03d3217e41536cee7c868860b5930160ad526/compiler-rt/include/sanitizer/msan_interface.h#L93-L96

So yes, we're passing a const pointer to an uninitialized portion of memory, which is typically pointless: the callee can't read it (UB) and it is not allowed to write it either.

But __msan_allocated_memory is special in this regard. The call is meaningful. And since it's a part of the Clang runtime, Clang should understand that this is meaningful.

Are you willing to report this upstream?

---

On our side, I think there are some nicer options:

1. Drop the call entirely (it's a noop because pubkey is already uninitialized). But it's easy to overlook in the future.
2. Initialize the variable.
3. Wrap the suppression inside the macro to make sure we always avoid this bug.

I tend to 3. It's perhaps the most complex option, but also the most future-proof?

[hebasto]

I think that's a Clang bug.

I agree with your analysis. That's why I chose to suppress the warning rather than take another approach.

3. Wrap the suppression inside the macro to make sure we always avoid this bug.

I tend to 3. It's perhaps the most complex option, but also the most future-proof?

That was my initial approach, but I didn’t manage to implement it properly. Could you suggest your patch?

[real-or-random]

That was my initial approach, but I didn’t manage to implement it properly. Could you suggest your patch?

Can you try this in checkmem.h?

#if defined(__has_feature)
#  if __has_feature(memory_sanitizer)
#    include <sanitizer/msan_interface.h>
#    define SECP256K1_CHECKMEM_ENABLED 1
#    if defined(__clang__)
#      define SECP256K1_CHECKMEM_UNDEFINE(p, len) do { \
         _Pragma("clang diagnostic push") \
         _Pragma("clang diagnostic ignored \"-Wuninitialized-const-pointer\"") \
         __msan_allocated_memory((p), (len)); \
         _Pragma("clang diagnostic pop") \
         } while(0)
#    else
#      define SECP256K1_CHECKMEM_UNDEFINE(p, len) __msan_allocated_memory((p), (len))
#    endif
#    define SECP256K1_CHECKMEM_DEFINE(p, len) __msan_unpoison((p), (len))
#    define SECP256K1_CHECKMEM_MSAN_DEFINE(p, len) __msan_unpoison((p), (len))
#    define SECP256K1_CHECKMEM_CHECK(p, len) __msan_check_mem_is_initialized((p), (len))
#    define SECP256K1_CHECKMEM_RUNNING() (1)
#  endif
#endif

---

I think that's a Clang bug.

I agree with your analysis. That's why I chose to suppress the warning rather than take another approach.

Would you be willing to report it upstream? Perhaps it will be fixed before the release of clang 21 and then we'll be able to drop this workaround.

[hebasto]

That was my initial approach, but I didn’t manage to implement it properly. Could you suggest your patch?

Can you try this in checkmem.h?

Thanks! Taken.

UPD. _Pragma(...) is a C99 feature.

Would you be willing to report it upstream?

llvm/llvm-project#160094.

Perhaps it will be fixed before the release of clang 21 and then we'll be able to drop this workaround.

https://github.com/llvm/llvm-project/releases/tag/llvmorg-21.1.1

[hebasto]

The feedback from @real-or-random has been addressed.

[real-or-random]

UPD. _Pragma(...) is a C99 feature.

Indeed. If I read correctly, clang has always supported it. https://clang.llvm.org/c_status.html

[real-or-random]

utACK mod nit

[real-or-random]

This PR is nice because it's an alternative to the Valgrind tests on clang-snapshot. That is, we can run the constant-time tests on clang-snapshot without Valgrind support.

[real-or-random]

Now that I think about it, why not run these three CI jobs on both clang and clang-snapshot?

[hebasto]

Thanks! Reworked.

[hebasto]

Rebased to resolve a conflict with the merged #1756 and taken @real-or-random's suggestion.

[real-or-random]

utACK ed9ea88 but let's see if CI succeeds

[hebasto]

... but let's see if CI succeeds

"Old" clang doesn't understand "-Wuninitialized-const-pointer"...

[hebasto]

... but let's see if CI succeeds

It's green now :)

[real-or-random]

utACK 53585f9