We had updates of certain header files in both Makefile.org and the
Makefile in the directory the header file lived in. This is error
prone and also sometimes generates slightly different results (usually
just a comment that differs) depending on which way the update was
done.
This removes the file update targets from the top level Makefile, adds
an update: target in all Makefiles and has it depend on the depend: or
local_depend: targets, whichever is appropriate, so we don't get a
double run through the whole file tree.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 0f539dc1a2)
Conflicts:
Makefile.org
apps/Makefile
test/Makefile
The function sk_zero is supposed to zero the elements held within a stack.
It uses memset to do this. However it calculates the size of each element
as being sizeof(char **) instead of sizeof(char *). This probably doesn't
make much practical difference in most cases, but isn't a portable
assumption.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 7132ac830f)
Sometimes it fails to format them very well, and sometimes it corrupts them!
This commit moves some particularly problematic ones.
Conflicts:
crypto/bn/bn.h
crypto/ec/ec_lcl.h
crypto/rsa/rsa.h
demos/engines/ibmca/hw_ibmca.c
ssl/ssl.h
ssl/ssl3.h
Reviewed-by: Tim Hudson <tjh@openssl.org>
indent will not alter them when reformatting comments
(cherry picked from commit 1d97c84351)
Conflicts:
crypto/bn/bn_lcl.h
crypto/bn/bn_prime.c
crypto/engine/eng_all.c
crypto/rc4/rc4_utl.c
crypto/sha/sha.h
ssl/kssl.c
ssl/t1_lib.c
Reviewed-by: Tim Hudson <tjh@openssl.org>
Add the wrapper to all public header files (Configure
generates one). Don't bother for those that are just
lists of #define's that do renaming.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Cherry-pick of commit 17e80c6bd0
Add hooks to support key agreement recipient info type (KARI) using
algorithm specific code in the relevant public key ASN1 method.
(cherry picked from commit 17c2764d2e)
This meant a slight renumbering in util/libeay.num due to symbols
appearing in 1.0.0-stable. However, since there's been no release on
this branch yet, it should be harmless.
- safestack macro changes for C++ were incomplete
- RLE decompression boundary case
- SSL 2.0 key arg length check
Submitted by: Google (Adam Langley, Neel Mehta, Bodo Moeller)
understand inline, while WIN32 ones insist on __inline. Well, there are
other compilers that insist on __inline. At the same time it turned out
that most compilers understand both __inline and inline. I could find
only one that doesn't understand __inline, Sun C. In other words it seems
that __inline as preferred choice provides better coverage...
