- 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
