Date: Tue, 15 Nov 1994 21:29:52 +0300 From: "Andrew A. Chernov, Black Mage" <ache@astral.msk.su> To: Nate Williams <nate@bsd.coe.montana.edu>, 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: <sCWuFokKx3@astral.msk.su> In-Reply-To: <199411151717.JAA02754@precipice.Shockwave.COM>; from Paul Traina at Tue, 15 Nov 1994 09:17:18 -0800 References: <199411151717.JAA02754@precipice.Shockwave.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199411151717.JAA02754@precipice.Shockwave.COM> Paul Traina
writes:
>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.
It is untrue, it needed for just simple malloc(), check Linux box f.e.
>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.
There is no conflicts, just the same prototypes from stdlib.h copied.
--
Andrew A. Chernov : And I rest so composedly, /Now, in my bed,
ache@astral.msk.su : That any beholder /Might fancy me dead -
FidoNet: -- temp down -- : Might start at beholding me, /Thinking me dead.
RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?sCWuFokKx3>