248f046 Make sure we're not using an uninitialized variable in secp256k1_wnaf_const(...) (practicalswift)
Pull request description:
Make sure we're not using an uninitialized variable in `secp256k1_wnaf_const(...)`:
```
In file included from src/secp256k1.c:15:0,
from src/tests.c:17:
src/ecmult_const_impl.h: In function ‘secp256k1_wnaf_const’:
src/ecmult_const_impl.h:117:20: warning: ‘u’ may be used uninitialized in this function [-Wmaybe-uninitialized]
wnaf[word] = u * global_sign;
^
```
**Note to reviewers:** Perhaps an `assert(…);` is a bit drastic. What would be a more graceful way to handle this? :-)
Tree-SHA512: 536cd7cc5b87a84fbaac578cecbba81b8d82e4672a30a2db9a674b82856132e79b0158a6a88609bc24942ebdbf1fcd2c4399a4c31ab0654b88ace9c0e6f1eaf3
Identifiers starting with an underscore and followed immediately by a capital letter are reserved by the C++ standard.
The only header guards not fixed are those in the headers auto-generated from java.
If you compile without ./configure --enable-exhaustive-tests=no,
this will create a binary ./exhaustive_tests which will execute
every function possible on a group of small order obtained by
moving to a twist of our curve and locating a generator of small
order.
Currently defaults to order 13, though by changing some #ifdefs
you can get a couple other ones. (Currently 199, which will take
forever to run, and 14, which won't work because it's composite.)
TODO exhaustive tests for the various modules
Designed with clear separation of the wNAF conversion, precomputation
and exponentiation (since the precomp at least we will probably want
to separate in the API for users who reuse points a lot.
Future work:
- actually separate precomp in the API
- do multiexp rather than single exponentiation
