no longer has access to the content of a memmory object. It does
this by either clearing (if the object memory remains cached) or
by calling munmap(2). ok millert@, deraadt@, guenther@

ok deraadt@

ok jmc@ deraadt@

never occur

make the behaviour -> use case connection.
help from jmc and jsing

help and ok from tom@ and deraadt@

with the added feature that released memory is cleared. Much input from various
developers. ok deraadt@ tom@

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

void return types 'return no value'. This is obvious and therefore
unneccessary to mention.
We spare rewind(3)'s sentence because espie@ pointed out that it's a
warning - the function masks a potential error.
This commit also adds a sentence to X509_free clarifying that it's
NULL-safe. This bit was discussed with doug@.
ok martijn@, sentiment supported by schwarze@

There is long-standing consensus that err(1, NULL) is the best idiom
after failure of malloc(3) and friends.
Quirk in the manual noticed by tb@.

The 'A' option elevated warnings to errors, and has been the default for some
time. Then warnings were effectively eliminated in favor of everything
being an error, but then the 'a' flag turned real errors into warnings!
Remove the 'a' option entirely. You shouldn't have used it anyway.
ok tb tdeval

for overflow. stop talking about old broken systems, there's little use
for such info.

breaking the hardlink between file system entries, confusing apropos(1).
Split malloc.conf(5) out of malloc(3) as suggested by deraadt@.
Feedback and OK jmc@, OK deraadt@ tedu@ jasper@.

don't want to give people the idea that this is non-portable (it
has been present since C89).  OK deraadt@ schwarze@

Suggested by millert@ and schwarze@.
OK schwarze@, millert@

ok deraadt@

Remove excessive technicalities on zero-sized objects as suggested by deraadt@.
contributions and ok deraadt@, ok jmc@ on an earlier version

and fix two instances of "new sentence, new line" while here
feedback and ok jmc@, ok doug@

The old man page had a lot of useful information, but it was all mixed
together which made it difficult to reference.  The main theme in this
commit is that the sections are more focused:
* DESCRIPTION describes the overall behavior
* RETURN VALUES describes what it may return (including implementation
defined values)
* EXAMPLES shows why we recently started an audit on malloc and realloc
usage in the tree.
* Added CAVEATS which describes what is implementation defined, gotchas
and security implications of misusing these functions
* Added IDIOMS which describes how these functions should or
should not be used
The MALLOC_OPTIONS section was left unchanged.  Function names were
added to DIAGNOSTICS and STANDARDS.  The MALLOC_OPTIONS and DIAGNOSTICS
sections were pushed down in the page so more pertinent information is
higher up.
This has gone through several revisions thanks to input from deraadt@
and schwarze@.  Ingo also helped with some of the mandoc formatting.
OK schwarze@ (as far as it is a good starting point and the code
snippets look ok)

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

- 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...

unmapping of freed allocations without disabling chunk randomisation
like the "Freeguard" ('F') option does. Make security 'S' option
use 'U' and not 'F'.
Rationale: guarding with no chunk randomisation is great for debugging
use-after-free, but chunk randomisation offers better defence against
"heap feng shui" style attacks that depend on carefully constructing a
particular heap layout so we should leave this enabled when requesting
security options.

jasper@

a section will help people looking for just the MALLOC_OPTIONS.
ok otto@ jmc@

to exist before exit for malloc to dump stats in it.
tweaks from jmc@
ok otto@,jmc@

brad and millert, with hints from guenther, jmc, and otto I think.
ok previous.

extra safeguard (FGJ). Idea from deraadt@; ok deraadt@ dlg@