GCC 14 false positive: -Wstringop-overflow in signal_handler::cancel_all

[nsoblath]

Building scarab with GCC 14 produces a spurious -Wstringop-overflow warning originating in signal_handler::cancel_all().

Warning

In member function 'std::__atomic_base<_IntTp>::__int_type std::__atomic_base<_IntTp>::load(std::memory_order) const [with _ITp = bool]',
    inlined from 'bool std::atomic<bool>::load(std::memory_order) const' at /usr/include/c++/14/atomic:117:26,
    inlined from 'void scarab::cancelable::cancel(int)' at scarab/library/utility/cancelable.hh:127:28,
    inlined from 'static void scarab::signal_handler::cancel_all(int)' at scarab/library/utility/signal_handler.cc:396:53:
/usr/include/c++/14/bits/atomic_base.h:501:31: warning: 'unsigned char __atomic_load_1(const volatile void*, int)' writing 1 byte into a region of size 0 overflows the destination [-Wstringop-overflow=]
cc1plus: note: destination object is likely at address zero

Root Cause

After inlining cancel_all → cancelable::cancel → std::atomic<bool>::load → __atomic_load_n(&f_canceled, ...), GCC 14's static analyzer loses the invariant that the cancelable* pointers in the list are non-null. It concludes this could be nullptr, placing &f_canceled at a near-zero address, and fires -Wstringop-overflow. This is a false positive — no null pointers are present at runtime.

Suggested Fix

Adding an explicit null guard in cancel_all before calling cancel() gives GCC the invariant it needs to eliminate the false positive:

if( c != nullptr ) c->cancel( signal );

Environment

• GCC 14 (Debian trixie)
• C++17
• Observed while building scarab as a submodule of dripline-cpp