- 0.7.0: Change ''NonceGen'' such that output when message is not present is different from when message is present but has length 0.
- 0.6.0: Change order of arguments and serialization of the message in the ''NonceGen'' hash function
Silence a compiler warning about an unitialized use of a scalar in case
the user tries to provide a 0-length list of commitments.
Also ensures that commitments have normalized field elements when they
are loaded into ges.
Besides improving the examples, this makes sure that the examples
import a variable (instead of a function), namely the static context,
from the library. This is helpful when testing MSVC builds, because
the MSVC linker tends to be awkward when importing variables.
This fixes a build issue with MSVC. While MSVC imports *functions*
from DLLs automatically when building a consumer of the DLL, it does
not import *variables* automatically. In these cases, we need an
explicit __declspec(dllimport).
This commit simply changes our logic to what the libtool manual
suggests, which has a very comprehensive writeup on the topic. Note
that in particular, this solution is carefully designed not to break
static linking. However, as described in the libtool manual,
statically linking the library with MSVC will output warning LNK4217.
This is still the best solution overall, because the warning is
merely a cosmetic issue.
8c7e0fc1de build: Add -Wreserved-identifier supported by clang (Tim Ruffing)
Pull request description:
This warns on certain identifiers reserved by the C standard, namely
* identifiers that begin with an underscore followed by an uppercase letter, and
* identifiers in the global namespace that begin with an underscore.
We had used such identifiers in the past for macros in include guards, and we should make sure that we don't reintroduce such identifiers going forward.
Note that C reserves more identifiers for "future library directions", e.g., identifiers that begin with "str" followed by a lowercase letter. But even the C standards committee has decided that this is somewhat silly and adopted a proposal [1] for C23 that removes the restriction that programs using these identifiers have UB. Instead, these identifiers are now "potentially reserved", which is not a normative restriction but simply an informative warning that the identifiers may become fully reserved in the future.
[1] https://www.open-std.org/jtc1/sc22/WG14/www/docs/n2625.pdf
ACKs for top commit:
sipa:
utACK 8c7e0fc1de
jonasnick:
tested ACK 8c7e0fc1de
Tree-SHA512: da0c5f1e36cffad2ab2f0b8055c8b3cb56e904d8bfea5a9eed9d6fa984359217b3ef3b9232bfb455cf4071c04a6c2a077e26d2a15b20d1eabc99b1fc61d2025c
This warns on certain identifiers reserved by the C standard, namely
* identifiers that begin with an underscore followed by an uppercase
letter, and
* identifiers in the global namespace that begin with an underscore.
We had used such identifiers in the past for macros in include guards,
and we should make sure that we don't reintroduce such identifiers
going forward.
Note that C reserves more identifiers for "future library directions",
e.g., identifiers that begin with "str" followed by a lowercase letter.
But even the C standards committee has decided that this is somewhat
silly and adopted a proposal [1] for C23 that removes the restriction
that programs using these identifiers have UB. Instead, these
identifiers are now "potentially reserved", which is not a normative
restriction but simply an informative warning that the identifiers
may become fully reserved in the future.
[1] https://www.open-std.org/jtc1/sc22/WG14/www/docs/n2625.pdf
9b60e3148d ci: Do not set git's `user.{email,name}` config options (Hennadii Stepanov)
Pull request description:
A cleanup after https://github.com/bitcoin-core/secp256k1/pull/1199.
git's `user.{email,name}` config options have been no longer required since 0ecf318851.
ACKs for top commit:
real-or-random:
utACK 9b60e3148d
Tree-SHA512: 04f737b0549a91ca992cd1410420e041549a07869eeef068e08971781ea8a4c88a2486e789df36a5ad370ccbbf5d9f7e49ab5f7c1d01faef358ffc4863aaf8e4
ef39721ccc Do not link `bench` and `ctime_tests` to `COMMON_LIB` (Hennadii Stepanov)
Pull request description:
The `bench` and `ctime_tests` binaries are users of the library, they should only be linked to the library, not the objects it was built from.
ACKs for top commit:
sipa:
utACK ef39721ccc
real-or-random:
utACK ef39721ccc
Tree-SHA512: 8bf8330adcce9bf6b21aceacf86e6aff7594762ab68b09257cfe2904fa0ce827377d5a13c0bed5acde74a2b420bb49460657c66d0068ecbe36dc162140876be4
c2415866c7 ci: Don't fetch git history (Tim Ruffing)
0ecf318851 ci: Use remote pull/merge ref instead of local git merge (Tim Ruffing)
Pull request description:
This steals two recent CI improvements from bitcoin/bitcoin. See individual commit messages.
ACKs for top commit:
sipa:
utACK c2415866c7
Tree-SHA512: 966130f45767c6bee8bc041d7e90a3166591a54c7cfccdcf4dff99aa4f6ccc2d02544fa7dca9fd020241349775da3cbd9bdbb041fcdd32de7426efd9dcc9c7f8
9b7d18669d Drop no longer used Autoheader macros (Hennadii Stepanov)
Pull request description:
A cleanup after #1178.
ACKs for top commit:
kevkevinpal:
utACK [9b7d186](9b7d18669d)
sipa:
utACK 9b7d18669d
real-or-random:
utACK 9b7d18669d
Tree-SHA512: ce95547683580bde46a55a6adc3dc46aca02fc86b0300ce0598d62ed47f1d77c4fa9ffd38dcda858655cefa6c940260d05f42cca294e7f3e7a46394b117c9ce9
The merge strategy on the remote may be different than the local one.
This may cause local merges to be different or fail completely. Fix this
by using the result of the remote merge.
(copied from bitcoin/bitcoin@fad7281d78)
eb6bebaee3 scalar: restrict split_lambda args, improve doc and VERIFY_CHECKs (Jonas Nick)
7f49aa7f2d ci: add test job with -DVERIFY (Jonas Nick)
620ba3d74b benchmarks: fix bench_scalar_split (Jonas Nick)
Pull request description:
scalar_split_lambda requires that the input pointer is different to both output
pointers. Without this fix, the internal benchmarks crash when compiled with
-DVERIFY.
This was introduced in commit 362bb25608 (which
requires configuring with --enable-endomorphism to exhibit the crash).
I tested that the new CI job would have caught this bug.
ACKs for top commit:
sipa:
utACK eb6bebaee3
real-or-random:
utACK eb6bebaee3
Tree-SHA512: c810545aefb01561ddb77b53618fa7acbb156ec13ab809c00523d4758492cafab1dfa01b6ebfb6195a3803bb49b16e63e8b0efcd1abb76ecefdb0476c3e483a3
scalar_split_lambda requires that the input pointer is different to both output
pointers. Without this fix, the internal benchmarks crash when compiled with
-DVERIFY.
This was introduced in commit 362bb25608 (which
requires configuring with --enable-endomorphism to exhibit the crash).
e39d954f11 tests: Add CHECK_ILLEGAL(_VOID) macros and use in static ctx tests (Tim Ruffing)
61841fc9ee contexts: Forbid randomizing secp256k1_context_static (Tim Ruffing)
4b6df5e33e contexts: Forbid cloning/destroying secp256k1_context_static (Tim Ruffing)
Pull request description:
As discussed in #1126.
For randomization, this has a history. Initially, this threw the illegal callback but then we changed it to be a no-op on non-signing contexts: 6198375218 But this was with (non-static) none/verification contexts in mind, not with the static context. If we anyway forbid cloning the static context, you should never a way to randomize a copy of the static context. (You need a copy because the static context itself is not writable. But you cannot obtain a copy except when using memcpy etc.)
ACKs for top commit:
sipa:
utACK e39d954f11
apoelstra:
ACK e39d954f11
Tree-SHA512: dc804b15652d536b5d67db7297ac0e65eab3a64cbb35a9856329cb87e7ea0fe8ea733108104b3bba580077fe03d6ad6b161c797cf866a74722bab7849f0bb60c
8f51229e03 ctime_tests: improve output when CHECKMEM_RUNNING is not defined (Jonas Nick)
Pull request description:
When seeing the output
```
Unless compiled under msan, this test can only usefully be run inside valgrind.
```
I thought that I would have to go back to the `configure` output to manually check if it was compiled under memsan to determine whether this test can be usefully run outside valgrind. But when we go into this branch then it was definitely not compiled under msan, which means that we can make the output clearer.
ACKs for top commit:
sipa:
utACK 8f51229e03
real-or-random:
utACK 8f51229e03
Tree-SHA512: a4953a158b1375d8fc3a2ee29e7014c5399becf5f75ffd3765c0141861e092fbc120003e00dfd25ec54b92a466e133377b96d5a9f4017c100aaf64fb9a045df1
2cd4e3c0a9 Drop no longer used `SECP_{LIBS,INCLUDE}` variables (Hennadii Stepanov)
613626f94c Drop no longer used `SECP_TEST_{LIBS,INCLUDE}` variables (Hennadii Stepanov)
Pull request description:
`SECP_INCLUDES`, `SECP_LIBS`, `SECP_TEST_LIBS` and `SECP_TEST_INCLUDES` were introduced in 78cd96b151.
The last usage of the `SECP_TEST_{LIBS,INCLUDE}` variables was removed in https://github.com/bitcoin-core/secp256k1/pull/983.
The last usage of the `SECP_LIBS` variable was removed in https://github.com/bitcoin-core/secp256k1/pull/831.
The last usage of the `SECP_INCLUDE` variable was removed in https://github.com/bitcoin-core/secp256k1/pull/1169.
ACKs for top commit:
sipa:
utACK 2cd4e3c0a9
real-or-random:
utACK 2cd4e3c0a9
Tree-SHA512: ceee39dfb74aaeaa9a1e52fba819f32cee8e08922872bca2bfd6db8575c9b4695da476a4b8e8579abb92d6484fbf461e691369b160ecbc792261dbb454349efb
