the SHA512/256 functions as well.

ok jmc naddy

with different magic numbers, so we need to add some functions instead
of just asking the user to truncate as desired. Sigh.
SHA512 is quite a bit faster than SHA256 on 64 bit CPUs,
but 256 bit hashes are usually quite sufficient. Best of both.
ok deraadt tom

from Jacob Berkman, ok beck@

tested by many (thanks!) ok tedu, guenther@

ok krw@ millert@

ok jca@ krw@

as readlink() will tell you that more cheaply.
ok millert@

ok deraadt@

ok deraadt@

functions out the way of the main body;
ok guenther

Merge the manual pages and call them deprecated there.
ok and manpage tweak jmc@, ok natano@

remove some references to differences between versions 6 and 7.
ok jmc, millert, tedu

ok deraadt@

with a little help from jmc@ for the man page bits
ok jca@  and a reluctant tedu@

In the event of a failure in _rs_allocate for rsx, we still have a reference to
freed memory for rs on return. Not a huge deal since we subsequently abort in
_rs_init, but it looks strange on its own.
ok deraadt@

For Windows, we are simply using calloc, which has two annoyances:
the memory has more permissions than needed by default, and it comes
from the process heap, which looks like a memory leak since this memory
is rightfully never freed.
This switches _rs_alloc on Windows to use VirtualAlloc, which restricts the
memory to READ|WRITE and keeps the memory out of the process heap.
ok deraadt@

chunk rnd), rm P: is default

double unmap and I experienced a much more unstable firefox.
discussed with otto on icb

expensive syscall, and we don't want to tie up other threads. there's no
need to hold the lock, so defer it to afterwards.
from Michael McConville
ok deraadt

for login.conf, and we don't want to go lower.

ok tedu@

ok natano@ millert@ deraadt@

in some cases.  Be consistent and use "dst" everywhere like for
strlcat(3) and strncat(3).  From Tim Kuijsten.

hppa reverse-stack gives us a valuable test case, but most developers don't
have a 2nd one to proceed further with this.
ok kettenis

From Michal Mazurek <akfaew at jasminek dot net>.
OK tedu@

additions and functionality changes.

The getenv(3) and unsetenv(3) functions already support this.
This will make it easier to emulate the glibc clearenv() function in ports.
Based on a diff from and OK jca@

Michael McConville

data isn't necessary.
ok mpi@, ok&tweak natano@

correctly - logically complete that now by removing MLINKS from base;
authors need only to ensure there is an entry in NAME for any function/
util being added. MLINKS will still work, and remain for perl to ease
upgrades;
ok nicm (curses) bcook (ssl)
ok schwarze, who provided a lot of feedback and assistance
ok tb natano jung

ok otto@