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
This change eases the use of alternate build systems by moving
the variables in `src/libsecp256k1-config.h` to compiler macros
for each invocation, preventing duplication of these variables
for each build system.
Co-authored-by: Ali Sherief <ali@notatether.com>
There are plenty of unreleased variants of libsecp256k1 version 0.1.0
(libsecp256k1.so.0.0.0) in the wild. We choose a new version number to allow a
clear distinction.
There are variants of 0.1.0 that are incompatible with the initial release,
hence we increase the minor version to arrive at version number 0.2.0. For the
same reason, we increase the LIB_VERSION_CURRENT and keep AGE at 0.
The changelog for 0.2.0 consists of the relevant changes since 2021-12-25, which
is the date when the initial release process PR was merged (and the library
version was set to a pre-release, see 423b6d19d3).
This is somewhat arbitrary but at least points readers to relevant changes.
41e8704b48 build: Enable some modules by default (Tim Ruffing)
Pull request description:
This has been discussed in https://github.com/bitcoin-core/secp256k1/issues/817#issuecomment-693198323 and I agree with the arguments brought up there.
Alternatively, we could not enable them and add a discussion to the readme why we discourage people from using the modules. I believe enabling ECDH is not very controversial. But what about recovery? Do we want to leave it off and instead give a reason?
ACKs for top commit:
sipa:
ACK 41e8704b48
jonasnick:
ACK 41e8704b48
Tree-SHA512: 1dd21037043f2b2c94a92cd2f31e69b505ba5b43119897bc0934966d9ccd84fc4fc20e7509af634f1c3a096710db1a2253090f5f1f107b9d258945a5546e9ba4
We don't enable the ECDSA recovery module, because we don't recommend
ECDSA recovery for new protocols. In particular, the recovery API is
prone to misuse: It invites the caller to forget to check the public
key (and the verification function always returns 1).
In general, we also don't recommend ordinary ECDSA for new protocols.
But disabling the ECDSA functions is not possible because they're not
in a module, and let's be honest: disabling ECDSA would mean to ignore
reality blatantly.
We had removed `PKG_PROG_PKG_CONFIG` in 21b2ebaf74
(#1090). But then then the not rebased (!) merge of 2be6ba0fed
(#1084) brought that macro back at another location, without git
complaining about a conflict.
Fixes#1127.
49e2acd927 configure: Improve rationale for WERROR_CFLAGS (Tim Ruffing)
8dc4b03341 ci: Add a C++ job that compiles the public headers without -fpermissive (Tim Ruffing)
51f296a46c ci: Run persistent wineserver to speed up wine (Tim Ruffing)
3fb3269c22 ci: Add 32-bit MinGW64 build (Tim Ruffing)
9efc2e5221 ci: Add MSVC builds (Tim Ruffing)
2be6ba0fed configure: Convince autotools to work with MSVC's archiver lib.exe (Tim Ruffing)
bd81f4140a schnorrsig bench: Suppress a stupid warning in MSVC (Tim Ruffing)
09f3d71c51 configure: Add a few CFLAGS for MSVC (Tim Ruffing)
3b4f3d0d46 build: Reject C++ compilers in the preprocessor (Tim Ruffing)
1cc0941414 configure: Don't abort if the compiler does not define __STDC__ (Tim Ruffing)
cca8cbbac8 configure: Output message when checking for valgrind (Tim Ruffing)
1a6be5745f bench: Make benchmarks compile on MSVC (Tim Ruffing)
Pull request description:
ACKs for top commit:
jonasnick:
ACK 49e2acd927
Tree-SHA512: 986c498fb218231fff3519167d34a92e11dea6a4383788a9723be105c20578cd483c6b06ba5686c6669e3a02cfeebc29b8e5f1428552ebf4ec67fa7a86957548
7f09d0f311 README: mention that ARM assembly is experimental (Jonas Nick)
80cf4eea5f build: stop treating schnorrsig, extrakeys modules as experimental (Jonas Nick)
Pull request description:
Fixes#992
ACKs for top commit:
real-or-random:
ACK 7f09d0f311
fanquake:
ACK 7f09d0f311 - When this is in, I think we'll do a subtree update in Core, and prune some build cruft on our side.
Tree-SHA512: 13deb82dcca88bacb2cd5c1c589a8d4af2277c4d675262337ae4d7e93eb41d43825dda4945ca1c202c36aaa2e6fd42de9c6d711fe8d71bce578368281db698b2
This removes a check for $ac_cv_prog_cc_c89 which is set by AC_PROG_CC
if defined(__STDC__) in the preprocessor. (Standard compliant compilers
are supposed to define __STDC__ to 1 but the value is actually not
checked here.)
Unfortunately, MSVC doesn't define it, so configure fails for MSVC.
This check is not very useful in practice. Over 30 years after C89 has
been released, there are no C compilers out there that are not
sufficiently compliant with C89 for the project. The only practically
relevant case was that the check rejected C++ compilers. A different
method to reject C++ compilers will be introduced in a later commit.
This removes code that detects the pkg-config tool. We used this
back in the days when we had dependencies. ;) It can always be brought
back if we'll need it in the future.
Note that we still deliver a .pc file for this library, and there is
code in Makefile.am to install it. But this does not require the
pkg-config tool; only consumers of the .pc file will need it. This can
be verified by running `make install` (maybe after `mkdir /tmp/pre` and
`./configure --prefix=/tmp/pre` and checking that the .pc file is
installed correctly.
This uses AM_PROG_AR to discover ar, which is the recommended way to do
so. Among other advantages, it honors the AR environment variable (as
set from the outside). The macro has been around since automake 1.11.2
(Dec 2011).
This commit also removes code that discovers ranlib and strip. ranlib
has been obsolete for decades (ar does its task now automatically), and
anyway LT_INIT takes care of discovering it. The code we used to set
STRIP was last mentioned in the automake 1.5 manual. Since automake 1.6
(Mar 2002), strip is discovered automatically when necessary (look for
the *private* macro AM_PROG_INSTALL_STRIP in the automake manual).
7c9502cece Add a copy of the CC0 license to the examples (Elichai Turkel)
42e03432e6 Add usage examples to the readme (Elichai Turkel)
517644eab1 Optionally compile the examples in autotools, compile+run in travis (Elichai Turkel)
422a7cc86a Add a ecdh shared secret example (Elichai Turkel)
b0cfbcc143 Add a Schnorr signing and verifying example (Elichai Turkel)
fee7d4bf9e Add an ECDSA signing and verifying example (Elichai Turkel)
Pull request description:
ACKs for top commit:
real-or-random:
ACK 7c9502cece
jonasnick:
ACK 7c9502cece
Tree-SHA512: c475cfd5b324b1e2d7126aa5bb1e7da25183b50adb7357d464c140de83d9097cb1bdc027d09aeadf167dbf9c8afd123235b0a1a742c5795089862418fafa1964
According to [autoconf 2.70](https://www.gnu.org/software/autoconf/manual/autoconf-2.70/html_node/Obsolete-Macros.html)
documentation, the `AC_PROG_CC_C89' is replaced by `AC_PROG_CC`, which
defines the same variable `ac_cv_prog_cc_c89`.
Avoids the following message:
```
configure.ac:23: warning: The macro `AC_PROG_CC_C89' is obsolete.
```
Also, remove deprecated `AM_PROG_CC_C_O`.
7dfceceea6 build: Remove #undef hack for ASM in the precomputation programs (Tim Ruffing)
bb36fe9be0 ci: Test `make precomp` (Tim Ruffing)
d94a37a20c build: Remove CC_FOR_BUILD stuff (Tim Ruffing)
ad63bb4c29 build: Prebuild and distribute ecmult_gen table (Tim Ruffing)
ac49361ed0 prealloc: Get rid of manual memory management for prealloc contexts (Tim Ruffing)
6573c08f65 ecmult_gen: Tidy precomputed file and save space (Tim Ruffing)
5eba83f17c ecmult_gen: Precompute tables for all values of ECMULT_GEN_PREC_BITS (Tim Ruffing)
fdb33dd122 refactor: Make PREC_BITS a parameter of ecmult_gen_build_prec_table (Tim Ruffing)
a4875e30a6 refactor: Move default callbacks to util.h (Tim Ruffing)
4c94c55bce doc: Remove obsolete hint for valgrind stack size (Tim Ruffing)
5106226991 exhaustive_tests: Fix with ecmult_gen table with custom generator (Tim Ruffing)
e1a76530db refactor: Make generator a parameter of ecmult_gen_create_prec_table (Tim Ruffing)
9ad09f6911 refactor: Rename program that generates static ecmult_gen table (Tim Ruffing)
8ae18f1ab3 refactor: Rename file that contains static ecmult_gen table (Tim Ruffing)
00d2fa116e ecmult_gen: Make code consistent with comment (Tim Ruffing)
3b0c2185ea ecmult_gen: Simplify ecmult_gen context after making table static (Tim Ruffing)
e43ba02cfc refactor: Decouple table generation and ecmult_gen context (Tim Ruffing)
22dc2c0a0d ecmult_gen: Move table creation to new file and force static prec (Tim Ruffing)
Pull request description:
This resolves#893, resolves#692 (and also resolvesbitcoin/bitcoin#22854).
- [x] Extract table generation to separate function in separate file (to be used by generation script and exhaustive tests)
- [x] Tidy up
- [x] Remove code that deals with non-static tables
- [x] Make functions that need ecmult_gen not depend on signing context
- [x] Rename stuff to make it fit the new structure and consistent with how we hande verification tables (#956)
- [x] Fix exhaustive tests
- [x] Make table generation function take generator as input
- [x] Overwrite the static tables with a table with custom generator in exhaustive tests
- [x] Overhaul script that generates table files
- [x] Make table generation function take PREC_BITS as input (I have some code already, just not yet in this branch)
- [x] Change generation script to generate three tables (for all three values of ECMULT_GEN_PREC_BITS)
- [x] Ship pre-built tables
- [x] Add pregenerated table file to repo
- [x] Remove generation of table file from build process (like in #956)
- [x] Remove left-over stuff (e.g., detecting a compiler running on the build machine) from build system
- [x] Final cleanups (copyright headers, commit, messages, etc.)
- [ ] (separate PR:) Make sure link-time optimization remove corresponding static tables (and code) when no signing/verifcation function is called
- [ ] (separate PR:) Compile precomputation as a separate object file and link it (https://github.com/bitcoin-core/secp256k1/pull/988#issuecomment-977813538)
- [ ] (separate PR:) Document the backwards-compatible API changes made in this PR and in #956.
- [ ] Maybe deprecate the static context
ACKs for top commit:
sipa:
ACK 7dfceceea6
robot-dreams:
ACK 7dfceceea6 (based on range-diff between 56284c7d44c0ed46e636588bfbf6c403b7dfa6c1 and 7dfceceea6)
Tree-SHA512: 6efb3f36f05efe3b79bbd877881fe1409f71fd6488d24c811b2e77d9f053bed78670dd1dcbb42ad780458a51c4ffa36de9cd6567271b22041dc7a122ceb677c5
- Improve Makefile.am for both prebuilt tables files
- On the way, tidy EXTRA_DIST: Move the header files to noinst_HEADERS,
where they conceptually belong, and add missing SECURITY.md to EXTRA_DIST
c0cd7de6d4 build: add -no-undefined to libtool LDFLAGS (fanquake)
fe32a79d35 build: pass win32-dll to LT_INIT (fanquake)
Pull request description:
This takes care of two of the outstanding issues in #923. One being initializing libtool with `win32-dll` and the other being the addition of `-no-undefined` to the libtool LDFLAGS. See each commit for more details.
Builders cross-compiling for Windows (including Core) will no-longer see:
```bash
libtool: warning: undefined symbols not allowed in x86_64-w64-mingw32 shared libraries; building static only
```
I'm planning on making some related changes downstream.
ACKs for top commit:
sipa:
utACK c0cd7de6d4. We indeed have done the work to propertly mark exported symbols, and AFAIK have no imported symbols apart from standard library ones.
real-or-random:
ACK c0cd7de6d4
hebasto:
ACK c0cd7de6d4
Tree-SHA512: 6756bc88ac439a27117a1341d82a801cef70354a9e7a563592ab3ac7298fbefdaa0a2c410ea3fba8953d53f254c449dc491069f30468db12791027a65dd02f80
This is only needed for the very oldest of non-POSIX-compatible shells.
Note that this code will also only be executed on macOS, where it'd be
very unlikely to run into such a shell.
Followup to #1019.
See:
https://github.com/koalaman/shellcheck/wiki/SC2006
Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>
214042a170 build: don't append valgrind CPPFLAGS if not installed (fanquake)
Pull request description:
Valgrinds CPPFLAGS, i.e `-I/usr/local/opt/valgrind/include`, are currently added to CPPFLAGS, regardless of whether valgrind is installed. This changes configure so that they are only added if valgrind is available. i.e the output of `brew list --versions valgrind` is non-null.
ACKs for top commit:
real-or-random:
ACK 214042a170
hebasto:
ACK 214042a170, tested on macOS Big Sur 11.6.1 (20G224, Intel).
Tree-SHA512: 5101636a0a12f1941b01967ca8eab7aa20f44db0d1ef4571a5ad6026bb89494b983465d34d93c8b17a260b695116792991da53d135bc19a3c9e974f5266a90af
Tim Ruffing
Jonas Nick
Hennadii Stepanov
Pieter Wuille
Russell O'Connor
Elliott Jin
Elichai Turkel
laanwj
fanquake