The dangers of replacing malloc()
D. J. Bernstein
djb at cr.yp.to
Fri Jun 27 23:11:03 PDT 2003
Terry Lambert writes:
> My argument in this case is that the valloc() interface is not
> portable, and you should not use it.
kqueue isn't portable, so you're saying nobody should use that, right?
Or do you admit that it's actually a good idea for people to use kqueue,
with a compile-time fallback to poll or select? Great.
Now, what happens when some other system decides to emulate kqueue (not
a huge surprise), using valloc (or some future xyzalloc), which in turn
uses sbrk directly (as valloc already does on a huge number of systems,
and as xyzalloc will probably do), rather than calling malloc?
That's right: it obliterates the data that I obtained from sbrk in my
malloc replacement. Kaboom. This is exactly the failure mode I explained
before. This is why the weak linking of the system's malloc is useless
for experienced programmers who care about portability.
(Since you asked: My valloc-uses-sbrk-directly demonstration was under
Linux, exactly as I said; specifically, Debian. Are you really so naive
as to think that all the Linux functions are listed in the manual?)
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
More information about the freebsd-performance