kris/boringssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
6bfdc63114
boringssl/include/openssl/crypto.h

59 lines
1.8 KiB
C
Raw Normal View History

Move public headers to include/openssl/ Previously, public headers lived next to the respective code and there were symlinks from include/openssl to them. This doesn't work on Windows. This change moves the headers to live in include/openssl. In cases where some symlinks pointed to the same header, I've added a file that just includes the intended target. These cases are all for backwards-compat. Change-Id: I6e285b74caf621c644b5168a4877db226b07fd92 Reviewed-on: https://boringssl-review.googlesource.com/1180 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2014-07-14 23:28:14 +01:00
/* Copyright (c) 2014, Google Inc.
*
* Permission to use, copy, modify, and/or distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
* SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
* OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
#ifndef OPENSSL_HEADER_CRYPTO_H
#define OPENSSL_HEADER_CRYPTO_H
#include <openssl/base.h>
Put the mem.h include back into crypto.h. 054e68267553e0b64975444741efa8099688d960 removed the compatibility include of mem.h in crypto.h. mem.h doesn't exist in upstream which defines these functions in crypto.h instead. The compatibility include should probably be restored to avoid causing all kinds of grief when porting consumers over. Change-Id: Idfe0f9b43ebee5df22bebfe0ed6dc85ec98b4de0 Reviewed-on: https://boringssl-review.googlesource.com/4530 Reviewed-by: Adam Langley <agl@google.com>
2015-04-24 15:15:31 +01:00
/* Upstream OpenSSL defines |OPENSSL_malloc|, etc., in crypto.h rather than
* mem.h. */
#include <openssl/mem.h>
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
#if defined(__cplusplus)
extern "C" {
#endif
/* crypto.h contains functions for initializing the crypto library. */
/* CRYPTO_library_init initializes the crypto library. It must be called if the
* library is built with BORINGSSL_NO_STATIC_INITIALIZER. Otherwise, it does
* nothing and a static initializer is used instead. */
OPENSSL_EXPORT void CRYPTO_library_init(void);
Compatibility changes for wpa_supplicant and OpenSSH. OpenSSH, especially, does some terrible things that mean that it needs the EVP_CIPHER structure to be exposed ☹. Damian is open to a better API to replace this, but only if OpenSSL agree too. Either way, it won't be happening soon. Change-Id: I393b7a6af6694d4d2fe9ebcccd40286eff4029bd Reviewed-on: https://boringssl-review.googlesource.com/4330 Reviewed-by: Adam Langley <agl@google.com>
2015-04-13 22:34:17 +01:00
/* Deprecated functions. */
#define OPENSSL_VERSION_TEXT "BoringSSL"
#define SSLEAY_VERSION 0
/* SSLeay_version is a compatibility function that returns the string
* "BoringSSL". */
OPENSSL_EXPORT const char *SSLeay_version(int unused);
Fix |SSLeay|. SSLeay is a compatibility function for OpenSSL, but I got it wrong. It doesn't return a string, it returns a number. This doesn't end up making any difference, but it fixes a warning when building OpenSSH. Change-Id: I327ab4f70313c93c18f81d8804ba4acdc3bc1a4a Reviewed-on: https://boringssl-review.googlesource.com/4811 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2015-05-20 00:30:20 +01:00
/* SSLeay is a compatibility function that returns OPENSSL_VERSION_NUMBER from
* base.h. */
OPENSSL_EXPORT unsigned long SSLeay(void);
Compatibility changes for wpa_supplicant and OpenSSH. OpenSSH, especially, does some terrible things that mean that it needs the EVP_CIPHER structure to be exposed ☹. Damian is open to a better API to replace this, but only if OpenSSL agree too. Either way, it won't be happening soon. Change-Id: I393b7a6af6694d4d2fe9ebcccd40286eff4029bd Reviewed-on: https://boringssl-review.googlesource.com/4330 Reviewed-by: Adam Langley <agl@google.com>
2015-04-13 22:34:17 +01:00
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
#if defined(__cplusplus)
} /* extern C */
#endif
Move public headers to include/openssl/ Previously, public headers lived next to the respective code and there were symlinks from include/openssl to them. This doesn't work on Windows. This change moves the headers to live in include/openssl. In cases where some symlinks pointed to the same header, I've added a file that just includes the intended target. These cases are all for backwards-compat. Change-Id: I6e285b74caf621c644b5168a4877db226b07fd92 Reviewed-on: https://boringssl-review.googlesource.com/1180 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2014-07-14 23:28:14 +01:00
Add a CRYPTO_library_init and static-initializer-less build option. Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12 00:11:15 +01:00
#endif /* OPENSSL_HEADER_CRYPTO_H */
Reference in New Issue Copy Permalink