This leaves behind files with names ending with '.iso-8859-1'. These
should be safe to remove. If something went wrong when re-encoding,
there will be some files with names ending with '.utf8' left behind.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Pointed out by Victor Vasiliev (vasilvv@mit.edu) via Adam Langley
(Google).
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 1e4a355dca)
(cherry picked from commit ac32a77cd6)
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
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
Conflicts:
crypto/rc4/rc4_enc.c
crypto/x509v3/v3_scts.c
crypto/x509v3/v3nametest.c
ssl/d1_both.c
ssl/s3_srvr.c
ssl/ssl.h
ssl/ssl_locl.h
ssl/ssltest.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 picked from commit 089f10e69e)
While ARMv7 in general is capable of unaligned access, not all instructions
actually are. And trouble is that compiler doesn't seem to differentiate
those capable and incapable of unaligned access. Side effect is that kernel
goes into endless loop retrying same instruction triggering unaligned trap.
Problem was observed in xts128.c and ccm128.c modules. It's possible to
resolve it by using (volatile u32*) casts, but letting STRICT_ALIGNMENT
be feels more appropriate.
(cherry picked from commit 3bdd80521a)
Submitted by: "Noszticzius, Istvan" <inoszticzius@rightnow.com>
Don't clear the output buffer: ciphers should correctly the same input
and output buffers.
rely on indirect call to block functions, they are not as fast as
non-consolidated routines. However, performance loss(*) is within
measurement error and consolidation advantages are considered to
outweigh it.
(*) actually one can observe performance *improvement* on e.g.
CBC benchmarks thanks to optimization, which also becomes
shared among ciphers.
