minek van on misc@. Thanks.
ok tb@, tj@
(and jmc@ is ok with the diff but can't ok the technical content).

a long sentence (from tj@).

free() error path.
ok otto@

a page.  This is not required by any standard and other malloc
implementation do not document (or implement) this. ok deraadt@

half a page and a page. ok jmatthew@ tb@

allocation to the size of the new allocation (instead of the requested size).
2. Previously realloc takes the easy way and always reallocates if C is
active. This commit fixes by carefully updating the recorded requested
size in all cases, and writing the canary bytes in the proper location
after reallocating.
3. Introduce defines to test if MALLOC_MOVE should be done and to
compute the new value.

This is a remnant from the original 4.4BSD code that had 'a' as
void * in the function args.  No binary change.  OK bluhm@

issue reported by scott cheloha
ok otto

been the default for ages, and I see no valid reason to be able to
disable it. ok natano@

quickly. In both cases it does not make sense to set hints on them.
So remove that option, which is just a remainder of old times when
malloc used to hold on to pages. ok stefan@

- redundant cast is redundant

time when we had national language support.
OK millert@

others.
C11 6.5.6.9 says:
When two pointers are subtracted, both shall point to elements of the
same array object, or one past the last element of the array object; the
result is the difference of the subscripts of the two array elements.
In these cases the objects are arrays of char so the result is defined,
and we believe that the report is based on a compiler incorrectly trapping
on defined behaviour.

prodded by otto@
ok kettenis@ otto@

Based on patch from yuanjie.huang at windriver.com via OpenSSH bz#2608,
with & ok millert, ok deraadt.

recomputing it all the time

error cases for -1 and 0 explicitly (it initially only checked for -1,
I updated it to also check for 0, and rzalamena@ figured out that 0
has to be checked in a differently).
OK millert@ rzalamena@

instead of chunk itself; does not change actual allocated size; ok tedu@

or prototypes.  Ditto for some of the char* and void* casts too.
verified no change to instructions on ILP32 (i386) and LP64 (amd64)
ok natano@ abluhm@ deraadt@ millert@

ok tedu@

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@