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)
in case something wants to create massive amounts of environment, like
a bit more than 1/4 of a 32-bit address space. unrealistic -- but why
audit one code path, and not treat others the same? then you have to
re-engage everytime you see the code. read the news, that isn't what
developers do. At least if the code paths look the same, there is hope,
because they are easier to verify for correctness. developers need
to give other developers a chance to want to care.
Mention that invalid bases do set EINVAL (as required by POSIX);
this part of the change uses part of an earlier patch by millert@.
Minor mdoc(7) cleanup and sync between the two pages while here.
Feedback and ok jmc@ and millert@.
required by the C standard when called with an invalid base:
strtoll(), strtoimax(), strtoul(), strtoull(), and strtoumax().
Same behaviour for strtoq() and strtouq() even though not standardized.
No functional change in strtol(), it was the only one already correct.
While here, simplify the conditional expression for checking the base
and sync whitespace and comments among the six files.
ok millert@
to hold the malloc lock across mmap syscalls in all cases. dropping it
allows another thread to access the existing chunk cache if necessary.
could be improved to be a bit more aggressive, but i've been testing this
simple diff for some time now with good results.
circular lists. Amazingly, they managed to extend the requirements to no
longer match the behavior of the VAX instructions they were modeled after,
so the trivial VAX ASM versions have to go. Nice job breaking it, X/Open!
Based on a diff from enh (at) google.com
ok miod@
Move <sys/mman.h> and raise(SIGKILL) calls to OS-specific headers.
On OpenBSD, move thread_private.h as well to arc4random.h.
On Windows, use TerminateProcess on getentropy failure.
ok deraadt@
6.11.5 - Storage-class specifiers:
The placement of a storage-class specifier other than at the
beginning of the declaration specifiers in a declaration is
an obsolescent feature.
Diff from Jean-Philippe Ouellet (jean-philippe (at) ouellet.biz)
into one if a system has an awesome getentropy(). In that case it
is valid to totally throw away the rsx state in the child. If the
getentropy() is not very good and has a lazy reseed operation, this
combining is a bad idea, and the reseed should probably continue to
use the "something old, something new" mix. _rs_allocate() can
accomodate either method, but not on the fly.
ok matthew
now using this as upstream code. The particular problem is systems
that contain older arc4random derivations lacking arc4random_uniform().
ok tedu miod
improve the random stream itself (it doesn't), but to introduce
noise in the arc4random calling pattern. Thanks to matthew@ who
pointed out bias in a previous diff, ok deraadt@ matthew@
Modern compiler toolchains are capable of optimizing even across
translation unit boundaries, so simply moving the memory clearing into
a separate function is not guaranteed to clear memory.
To avoid this, we take advantage of ELF weak symbol semantics, and
insert a call to an empty, weakly named function. The semantics of
calling this function aren't determinable until load time, so the
compiler and linker need to keep the memset() call.
There are still ways a toolchain might defeat this trick (e.g.,
optimistically expecting the weak symbol to not be overloaded, and
only calling memset() if it is; promoting weak symbols to strong
symbols at link-time when emitting a static binary because they won't
be interposed; implementing load-time optimizations). But at least
for the foreseeable future, these seem unlikely.
ok deraadt
doug