Tim Ruffing

Thanks for acknowledging. I saw that you've added the "documentation" label. Fixing the docs will certainly be an improvement. Let me say though that I think the best fix is...

> The suggested approach is incomplete. Wouldn't it be better to document build prerequisites, which also include `automake`, `libtool`, etc? Yes, I think so, and this should probably simply go...

@vhnatyk Have you checked the latest revisions? We made a lot of progress for use on embedded devices in the past weeks (PRs #557, #566, #595, #596). In particular you...

This issue is related to #622.

Useful resources: https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/yang https://media.ccc.de/v/35c3-9788-memsad So we all know that there no single right way of doing this. For building on #448 I think I'll switch to memset + memory barrier...

I think this depends on #929

> That is, on MSVC, we could define u128 as a `struct { uint64_t lo, hi; }` and then implementing that with its intrinsics. This is what we do in...

> If u128 is implemented using a struct in just MSVC Restricting this to MSVC is what we did, and it works rather well. `__int128` is the "intrinsic" way on...

> Here's a mashup of fiat-crypto secpk256k1 C code with uint128 only used to implement full 64-bit arithmetic: [gist.github.com/andres-erbsen/7dd3ce006f7361840225f081bcdd9ad7](https://gist.github.com/andres-erbsen/7dd3ce006f7361840225f081bcdd9ad7) This should be a good starting point for experimentation with intrinsics...

> I think we might be after `-Wl,--no-allow-shlib-undefined`, though, and only for the shared lib as that's what we care about. `--no-undefined` is strictly stronger, I guess, and should also...