ok crickets@

beauty sleep.  He's probably having a nightmare about this right now....
ok tedu

these files similar in layout to the other md Makefile.inc; no functional
change.

wherever it decides it would like them. first step. ok deraadt dlg djm

uses the `umul' and `udiv' instructions directly, which are not supported
on v7 processors.

or the !SSLASM list of files applies. This allows for an arch-specific
Makefile.inc to not specify SSLASM.

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