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@

(MALLOC_OPTIONS=L). It was too slow to turn on by default, and we
don't do optional security.
requested by deraadt@ grumbling ok otto@

Move all runtime options into a structure that is made read-only
(via mprotect) after initialisation to protect against attacks that
overwrite options to turn off malloc protections (e.g. use-after-free)
Allocate the main bookkeeping data (struct dir_info) using mmap(),
thereby giving it an unpredictable address. Place a PROT_NONE guard
page on either side to further frustrate attacks on it.
Add a new 'L' option that maps struct dir_info PROT_NONE except when
in the allocator code itself. Makes attacks on it basically impossible.
feedback tedu deraadt otto canacar
ok otto

the page as possible (i.e. make malloc option P a default).
ok art@ millert@ krw@

ok jmc@