engines/e_padlock.c assumes that for all x86 and x86_64 platforms, the
lower level routines will be present. However, that's not always
true, for example for solaris-x86-cc, and that leads to build errors.
The better solution is to have configure detect if the lower level
padlock routines are being built, and define the macro PADLOCK_ASM if
they are, and use that macro in our C code.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1510)
There is a preference for suffixes to indicate that a function is internal
rather than prefixes. Note: the suffix is only required to disambiguate
internal functions and public symbols with the same name (but different
case)
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
There was a lot of naming inconsistency, so we try and standardise on
one form.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
We had the function EVP_CIPHER_CTX_cipher_data which is newly added for
1.1.0. As we now also need an EVP_CIPHER_CTX_set_cipher_data it makes
more sense for the former to be called EVP_CIPHER_CTX_get_cipher_data.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Note: there's a larger number of implementations in crypto/evp/ that
aren't affected because they include evp_locl.h. They will be handled
in a separate commit.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Just as with the OPENSSL_malloc calls, consistently use sizeof(*ptr)
for memset and memcpy. Remove needless casts for those functions.
For memset, replace alternative forms of zero with 0.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Add a dozen more const declarations where appropriate.
These are from Justin; while adding his patch, I noticed
ASN1_BIT_STRING_check could be fixed, too.
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
(with introduction of 64-bit support alloca must be declared and there
is no standard way of doing that, switching to __bultin_alloca is
considered appropriate because code explicitly targets gcc anyway).
