Use a conditional move of the same kind we use for the affine points
in the storage type instead of multiplying with the infinity flag
and adding. This results in fewer constructions to worry about for
sidechannel behavior.
It also might be faster: It doesn't appear to benchmark as slower for
me at least; but I think the CMOV is faster than the mul_int + add,
but slower than the set+add; making it a wash.
Unbraced statements spanning multiple lines has been shown in many
projects to contribute to the introduction of bugs and a failure
to catch them in review, especially for maintenance on infrequently
modified code.
Most, but not all, of the existing practice in the codebase were not
cases that I would have expected to eventually result in bugs but
applying it as a rule makes it easier for other people to safely
contribute.
I'm not aware of any such evidence for the case with the statement
on a single line, but some people strongly prefer to never do that
and the opposite rule of "_always_ use a single line for single
statement blocks" isn't a reasonable rule for formatting reasons.
Might as well brace all these too, since that's more universally
acceptable.
[In any case, I seem to have introduced the vast majority of the
single-line form (as they're my preference where they fit).]
This also removes a broken test which is no longer needed.
C doesn't include the null in an array initilized from a
string literal if it doesn't fit, in C++ this is invalid.
The vararray style prototypes and init+calc also changed in
this commit are not C89 enough for some tools.
This makes the software more portable to embedded systems
and static analysis tools.
Sadly, it can't result in identical binaries because C99 mixed
declarations seem to make GCC emit superfluous stack-pointer
updates. The compiler is also somewhat dependent on the
declaration order.
GCC (and clang) supports extensions to annotate functions so that their
results must be used and so that their arguments can't be statically
provable to be null. If a caller violates these requirements they
get a warning, so this helps them write correct code.
I deployed this in libopus a couple years ago with good success, and
the implementation here is basically copied straight from that.
One consideration is that the non-null annotation teaches the optimizer
and will actually compile out runtime non-nullness checks as dead-code.
Since this is usually not whats wanted, the non-null annotations are
disabled when compiling the library itself.
The commit also removes some dead inclusions of assert.h and introduces
compatibility macros for restrict and inline in preparation for some
portability improvements.
Magnitude m means values are allowed to be up to 2 * 0xFFF...FFF * m,
while the argument passed to secp256k1_fe_negate didn't take the 2 into
account. Fix this.
This makes a basic effort and has not been audited.
Doesn't appear to have a measurable performance impact on bench.
It also adds a secp256k1_num_free to secp256k1_ecdsa_pubkey_create.
- Uses a similar approach to the latest 64bit _normalize.
- Add one useful optimization back into the 64bit _normalize too.
Performance of 'bench' improved by around 0.5% for the 32bit field (but tested on a 64-bit machine).
