Date: Tue, 15 Nov 1994 09:17:18 -0800 From: Paul Traina <pst@shockwave.com> To: Nate Williams <nate@bsd.coe.montana.edu> Cc: CVS-commiters@freefall.cdrom.com, cvs-include@freefall.cdrom.com Subject: Re: cvs commit: src/include malloc.h Makefile Message-ID: <199411151717.JAA02754@precipice.Shockwave.COM> In-Reply-To: Your message of "Tue, 15 Nov 1994 10:10:15 MST." <199411151710.KAA09414@bsd.coe.montana.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Nate Williams <nate@bsd.coe.montana.edu> Subject: Re: cvs commit: src/include malloc.h Makefile > Why would we want the system5 fatmalloc? Why do we want malloc() at all? Umm, do you have *any* idea what you are talking about? The libmalloc() No, I didn't. supplied in 1.1.5 is Mark Moraes replacement malloc() that is *much* more frugal on memory use with only a slight performance hit. It was my intent to replace the version in 2.X with this version, but due to lack of time and testing on my part I didn't get time to do it. By adding it to 2.X we have it in public where it *may* get more testing than by sitting doing nothing. It is leaner/meaner than the stock version and not fat in the least bit. The second question seems rather silly to me. Gee, I don't know why we want malloc(), maybe since the ability to do dynamic memory in programs is generally considered a good feature? Yes, indeed. However, the idea as I understand here is that we're including a /usr/include/malloc.h for SystemV compatibility. Searching back through my ugly USG memory, malloc.h is _intended_ to only be included if you're linking against the SystemV libmalloc, you weren't SUPPOSED to use it unless you were doing so, because all the diags weren't there and the internal structures between the dynamic allocation code in 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. One of the biggest problems I have with malloc.h is that there is a conflict between declaring malloc as returning type char * and void *. You really want malloc to be defined as returning void *, and that's how it SHOULD be defined in malloc.h, but almost everyone defines it as char * for stupid historical reasons. If you define it one way, and someone else does it the other way, you generate an error or a warning. If you don't define it at all, the worse you get is a warning, and most of the time you don't get that at all because people seem to insist on casting the output of malloc (more historical stupidity from the days before void * existed).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199411151717.JAA02754>