Date: Tue, 15 Nov 1994 10:27:19 -0700 From: Nate Williams <nate@bsd.coe.montana.edu> To: Paul Traina <pst@shockwave.com> Cc: CVS-commiters@freefall.cdrom.com, cvs-include@freefall.cdrom.com Subject: Re: cvs commit: src/include malloc.h Makefile Message-ID: <199411151727.KAA09547@bsd.coe.montana.edu> In-Reply-To: Paul Traina <pst@shockwave.com> "Re: cvs commit: src/include malloc.h Makefile" (Nov 15, 9:17am)
next in thread | previous in thread | raw e-mail | index | archive | help
[ Having /usr/include/malloc.h ] > Yes, indeed. However, the idea as I understand here is that we're including a > /usr/include/malloc.h for SystemV compatibility. Yeah, that's a bad thing. However, IF andrew is going to put it in, why not add some additional functionality besides the include file. I don't necessarily agree that it should go in /usr/include, but *if* it is, let's go all the way and get a decent malloc implementation at the same time. It is actually a very nice package, providing debugging support and other helpful features. > libc and libmalloc were completely different. The USG libmalloc was the > fast-but-bloated-and-stupid malloc, while the libc malloc was the one normal > mortals would use. Ahh, but in our case (if we added libmalloc), the opposite would be true. We have a fast-but-bloated malloc in libc, while the version in libmalloc is not-as-fast-and-not-so-bloated. ;) > If you don't define it at all, the worse you get is a warning, Except that many (mostly Linux) programs include <malloc.h>, and compiles simply fail. The decision was made (apparently) to create a dummy malloc.h which would allow compiles to work, even though the offending programs shouldn't use malloc.h. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199411151727.KAA09547>