Workaround for GCC bug 95189 using -fno-builtin-memcmp

[luke-jr]

For native builds, this builds and runs a test for the bug itself.

When cross-compiling, it assumes any 9.x or 10.x GCC is affected.

The second commit (native test) may be more than this project needs.

[sipa]

Hmm, this is a lot simpler than what I tried!

The only argument against this would be that it doesn't protect non-autoconf builds.

[real-or-random]

The only argument against this would be that it doesn't protect non-autoconf builds.

Yes, but I think that's an important argument.

Also, the code of secp256k1_memcmp_var is fewer lines and easier to reason about than this autoconf code.

[luke-jr]

I like @gmaxwell 's suggestion to just have a test case for it, for non-autotools builders.

Another option would be to add a define in configure that the code #ifndef/#errors without...

[real-or-random]

I like @gmaxwell 's suggestion to just have a test case for it, for non-autotools builders.

Hm but this should be a self-test then. Not everyone runs the tests.

Another option would be to add a define in configure that the code #ifndef/#errors without...

Then people will just remove the #error.

Also every form of conditional compilation makes it harder for us to test on Travis reliably.

I think all of these are more or less acceptable solutions but each of them has some disadvantages. What's the disadvantage of secp256k1_memcmp_var?

[sipa]

I think I'd be ok with this + a selftest for broken memcmp, but I don't see any downsides to the secp256k1_memcmp_var approach instead.

[luke-jr]

No particular downsides to the other approach other than it being ugly. I won't be offended if you choose it over this. ;)

[gmaxwell]

Given how trivial memcmp is, I'd rather the consistency of everyone running the same thing and not more optional/conditional code to worry about.

[elichai]

I agree with @gmaxwell, memcmp is trivial to implement, and this flag anyway won't help with places where stdlib can call __builtin_memcmp directly (not sure if this is a thing in libc or just in libc++ though)

[luke-jr]

Note that secp256k1_memcmp_var obviously can't help with stdlib calling __builtin_memcmp either ;)

[elichai]

Note that secp256k1_memcmp_var obviously can't help with stdlib calling __builtin_memcmp either ;)

obviously :)

[gmaxwell]

I don't believe there are any other stdlib functions called by the library at runtime other than memcpy (assuming you're built without malloc, otherwise I believe the only library function calls are malloc/free/memcpy).

[roconnor-blockstream]

memset.

[luke-jr]

The custom memcmp got merged, so I guess this is irrelevant now?