locality on 64-bit platforms (and fixes IA64 assembler-empowered build:-).
The choice is guarded by newly introduced AES_LONG macro, which needs
to be defined only on 16-bit platforms which we don't support (not that
I know of). Meaning that one could as well skip long option altogether.

hand-coded zero-copy AES_cbc_encrypt.

PR: 991

PR: 990
Submitted by: Mike Frysinger <vapier@gentoo.org>

gets _POSIX_C_SOURC and _ANSI_C_SOURCE defined, which stops u_int from
being defined, and that breaks havock into the rest of the standard
headers...  *sigh*

isascii() on DEC/Compaq/HP C for VMS.

 - Enforce that there should be no policy settings when the language
   is one of id-ppl-independent or id-ppl-inheritAll.
 - Add functionality to ssltest.c so that it can process proxy rights
   and check that they are set correctly.  Rights consist of ASCII
   letters, and the condition is a boolean expression that includes
   letters, parenthesis, &, | and ^.
 - Change the proxy certificate configurations so they get proxy
   rights that are understood by ssltest.c.
 - Add a script that tests proxy certificates with SSL operations.

Other changes:

 - Change the copyright end year in mkerr.pl.
 - make update.

memory BIO (for example from SMIME_read_PKCS7 and detached data) avoid lots
of slow memory copies from the memory BIO by saving the content in a
temporary read only memory BIO.

PR: 989

environments.

performance on recent microarchitectures.

PR: 998

`mask' and `emask' getting that operation done once each.

Patch supplied by Nils Larsch <nils.larsch@cybertrust.com>

really needed now, but may be needed in the future, who knows?).

Well, no-options seem to be busted in HEAD currently, which should/will be
fixed one way or another (see PR#989 for a possible alternative).

replace *whole* aes_core.c, not only AES_[de|en]crypt routines.

PR: 989
Submitted by: Doug Kaufman

performance, but anyway...

const.

PR: 949

I change from -notall to -none synonym in irix rules to improve backward
compatibility with IRIX 5.x.
PR: 987

it makes more sense to strive for broader binary compatibility...

essentially cosmetic modification...