Gregory Maxwell

I don't believe I've ever personally encountered multiple package files for build time optional features, though I'm sure it exists. It's much more common to use feature testing (or... even...

> only if you seriously care about performance. I think the vast majority of users would be ones that don't want to have an extra 19kilobytes in their binary. >...

Experimental features just don't have any promises. Breaking the interface for one isn't any kind of API break because no API commitment was made at all. It may not be...

I was recently benchmarking gcc 9.2 on i.MX6 and the code you wrote was still a massssiiiivvvveee speedup. :) (if you dig through the safegcd thread you can see some...

Right, if you operate on a zeroed pubkey you've failed to perform required error handling.

@elichai if they've written their code like that-- (i agree, easy mistakes to make, -- not just in go but in C too) then they're potentially vulnerable to worse things......

I think that won't work well: they can show up in 100 different places, they'll move around, etc. Obviously we're not going to be maintaining a separate file with every...

Yeah, we should talk to the valgrind authors. This isn't technically a valgrind bug and GCC has previously fixed the behaviour. But LLVM/Clang indicate that they will not change the...

Do we know anyone that is involved in the C standard? ... perhaps they could be convinced to at least elevate self-memcpy to implementation defined. :) I normally don't consider...

Clang devs don't have any control over libc. But if they think must-support-memcpy-self is a reasonable requirement for memcpy, then isn't that a case that it's a reasonable implementation defined...