The sparcv9 BN code is not enabled, as it expects to run on a 32-bit
userland and will need to be fixed for 64-bit userland first.

Note that GCM128 Neon code is currently not built (and thus not tested), as
the current toolchain does not support Neon instructions.

switch to generating them by default. prodded by deraadt and sthen

2. Pull up the actual minor processing code into the switch that
parses it.
3. atoi is actually simpler than strtonum in this case, but check the
input beforehand so we don't get unexpected results.
4. Slightly more consistent style between various parse and check and
increment operations on salt.
ok deraadt

Assembler bits for AES remain commented out as they run slower than the C code.

things. Worth doing as it's twice faster than the C code.

RC4 assembler code is not used, as it runs about 35% slower than the C code.

ok deraadt@

a free chunk at random and may allow to increase delayed chunk array.
ok otto

default and the new 'j' option to disable this; ok jmc@

ok miod@

we always junk small chunks now, and the first part of pages,
but only after free. J still does the old thing. j disables everything.
Consider experimental as we evaluate performance in the real world.
ok otto

okay otto@

Should improve sparc64 and other be archs. ok matthew@ miod@

ok miod@

- use <>

malloc can, as always, be emulated via realloc(NULL).
ok deraadt

Like calloc(), except without the cleared-memory gaurantee
ok beck guenther, discussed for more than a year...

From Ben Cornett (ben (at) lantern.is)

APIs that pass times as longs will have to change at some point...
Bump major on both libcrypto and libssl.
ok tedu@

non-dangerous use functions is difficult.
ok guenther

but rather figure out the endianness from <machine/endian.h> automagically;
help from guenther@
ok jca@ guenther@ beck@ and the rest of the `Buena SSL rampage club'

are still some 3rd-party code using it, and fixing them is not trivial.
As an excuse gift, the memory leaks on failure in resurrected a_set.c have
been fixed.

ok deraadt

ok deraadt.

supposedly smart compilers from optimizing memory cleanups away. Understood.
Ok, in case of an hypothetically super smart compiler, OPENSSL_cleanse() had
to be convoluted enough for the compiler not to recognize that this was
actually bzero() in disguise. Understood.
But then why there had been optimized assembler versions of OPENSSL_cleanse()
is beyond me. Did someone not trust the C obfuscation?

fragments, to ease maintainance, and see through the fog of bugs.
"looks good" deraadt@

free software project. ok beck deraadt
Ports calling FIPS_mode_set(1): mongodb

gets a second trim.

now removed engines.

of des_old.h routines, acting as wrappers about the OpenSSL UI API.
Nothing should use these functions directly.
Riding the recent libcrypto major bump (in a `des' car).

are not please fix your operating system. Replace mem.c with an API-compatible
wrapper that just calls the system functions and does not allow a one word
modification of a variable in a running shared library to turn on memory
debug functions that expose things that should not be seen.
ok tedu@

ok beck deraadt