Date: 28 Jun 2003 06:11:33 -0000 From: "D. J. Bernstein" <djb@cr.yp.to> To: freebsd-performance@freebsd.org Subject: Re: The dangers of replacing malloc() Message-ID: <20030628061133.64427.qmail@cr.yp.to> References: <20030626034138.88365.qmail@cr.yp.to> <3EFA9CA3.E616B54C@mindspring.com> <20030626210507.36261.qmail@cr.yp.to> <3EFC1B2A.344674DD@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030628061133.64427.qmail>