This was done by the following
find . -name '*.[ch]' | /tmp/pl
where /tmp/pl is the following three-line script:
print unless $. == 1 && m@/\* .*\.[ch] \*/@;
close ARGV if eof; # Close file to reset $.
And then some hand-editing of other files.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
There are header files in crypto/ that are used by a number of crypto/
submodules. Move those to crypto/include/internal and adapt the
affected source code and Makefiles.
The header files that got moved are:
crypto/cryptolib.h
crypto/md32_common.h
Reviewed-by: Rich Salz <rsalz@openssl.org>
After the finale, the "real" final part. :) Do a recursive grep with
"-B1 -w [a-zA-Z0-9_]*_free" to see if any of the preceeding lines are
an "if NULL" check that can be removed.
Reviewed-by: Tim Hudson <tjh@openssl.org>
OPENSSL_NO_RIPEMD160, OPENSSL_NO_RIPEMD merged into OPENSSL_NO_RMD160
OPENSSL_NO_FP_API merged into OPENSSL_NO_STDIO
Two typo's on #endif comments fixed:
OPENSSL_NO_ECB fixed to OPENSSL_NO_OCB
OPENSSL_NO_HW_SureWare fixed to OPENSSL_NO_HW_SUREWARE
Reviewed-by: Richard Levitte <levitte@openssl.org>
BUF_mem_grow and BUF_mem_grow_clean. Refuse attempts to shrink buffer
in CRYPTO_realloc_clean.
Thanks to Tavis Ormandy, Google Security Team, for discovering this
issue and to Adam Langley <agl@chromium.org> for fixing it. (CVE-2012-2110)
during "make errors" and thus during "make update".
Fix lots of bugs that util/ck_errf.pl can detect automatically.
Various others of these are still left to fix; that's why
"make update" will complain loudly when run now.
functions and macros.
This change has associated tags: LEVITTE_before_const and
LEVITTE_after_const. Those will be removed when this change has been
properly reviewed.
sure they are available in opensslconf.h, by giving them names starting
with "OPENSSL_" to avoid conflicts with other packages and by making
sure e_os2.h will cover all platform-specific cases together with
opensslconf.h.
I've checked fairly well that nothing breaks with this (apart from
external software that will adapt if they have used something like
NO_KRB5), but I can't guarantee it completely, so a review of this
change would be a good thing.
most of the old wrappers. A few of the old versions remain
because they are non standard and the corresponding ASN1
code has not been reimplemented yet.
