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.
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@
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@
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
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
1. Optionally add random "canaries" to the end of an allocation. This
requires increasing the internal size of the allocation slightly, which
probably results in a large effective increase with current power of two
sizing. Therefore, this option is only enabled via 'C'.
2. When writing junk (0xdf) to freed chunks (current default behavior),
check that the junk is still intact when finally freeing the delayed chunk
to catch some potential use after free. This should be pretty cheap so
there's no option to control it separately.
ok deraadt tb
C standard are all weak.
Apply __{BEGIN,END}_HIDDEN_DECLS to gdtoa{,imp}.h, hiding the
arch-specific __strtorx, __ULtox_D2A, __strtorQ, __ULtoQ_D2A symbols.
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.
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@