https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
Tim Ruffing <public at timruffing dot de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |public at timruffing dot de
--- Comment #17 from Tim Ruffing <public at timruffing dot de> ---
Created attachment 49276
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49276&action=edit
Hacky patch that makes GCC print a diagnostic message if hitting the bug
We hit this bug in a test case in secp256k1, the cryptography library used in
Bitcoin Core. The bug appeared pretty scary to us at first glance because
memcmp is widely used. After looking at the GCC patch that fixes this, we
believe that this bug only occurs when
* at least one of the compared byte arrays is constant and has a zero byte in
position 0, 1, 2, or 3, *and*
* the result of the memcmp isn't immediately used in a "== 0" or "!= 0" test
(or equivalently "if(memcmp(...))" or "if(!memcmp(...))").
In particular the second condition makes this bug pretty rare and explains why
it's mostly hit in non-inlined memcmp wrappers. (But in our case we hit it with
a "<" comparison. )
For anyone else who's concerned about this bug, we've created a hacky patch
(co-authored by Russell O'Connor) for the GCC versions with this bug that makes
GCC print a diagnostic message if it emits wrong code due to this bug. We think
the message is sound but it would be great if someone could confirm this.
