Merge bitcoin-core/secp256k1#1231: Move SECP256K1_INLINE macro definition out from include/secp256k1.h

8e142ca410 Move `SECP256K1_INLINE` macro definition out from `include/secp256k1.h` (Hennadii Stepanov)
77445898a5 Remove `SECP256K1_INLINE` usage from examples (Hennadii Stepanov)

Pull request description:

  From [IRC](https://gnusha.org/secp256k1/2023-01-31.log):
  > 06:29 \< hebasto\> What are reasons to define the `SECP256K1_INLINE` macro in user's `include/secp256k1.h` header, while it is used internally only?
  > 06:32 \< hebasto\> I mean, any other (or a new dedicated) header in `src` looks more appropriate, no?
  > 06:35 \< sipa\> I think it may just predate any "utility" internal headers.
  > 06:42 \< sipa\> I think it makes sense to move it to util.h

  Pros:
  - it is a step in direction to better organized headers (in context of #924, #1039)

  Cons:
  - code duplication for `SECP256K1_GNUC_PREREQ` macro

ACKs for top commit:
  sipa:
    utACK 8e142ca410
  real-or-random:
    utACK 8e142ca410

Tree-SHA512: 180e0ba7c2ef242b765f20698b67d06c492b7b70866c21db27c18d8b2e85c3e11f86c6cb99ffa88bbd23891ce3ee8a24bc528f2c91167ec2fddc167463f78eac
This commit is contained in:
Tim Ruffing
2023-04-20 18:03:21 +02:00
15 changed files with 29 additions and 13 deletions

View File

@@ -77,7 +77,7 @@ static void print_hex(unsigned char* data, size_t size) {
#include <Windows.h>
#endif
/* Cleanses memory to prevent leaking sensitive info. Won't be optimized out. */
static SECP256K1_INLINE void secure_erase(void *ptr, size_t len) {
static void secure_erase(void *ptr, size_t len) {
#if defined(_MSC_VER)
/* SecureZeroMemory is guaranteed not to be optimized out by MSVC. */
SecureZeroMemory(ptr, len);