Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.unix.xenix
Subject: Re: smail2.5
Message-ID: <6516@brl-smoke.ARPA>
Date: Sat, 3-Oct-87 22:04:05 EDT
Article-I.D.: brl-smok.6516
Posted: Sat Oct  3 22:04:05 1987
Date-Received: Sun, 4-Oct-87 07:21:40 EDT
References: <398@auscso.UUCP> <132@sdti.UUCP> <29699@sun.uucp> <135@sdti.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 14
Keywords: smail Xenix trouble
Xref: utgpu comp.unix.questions:3924 comp.unix.wizards:4330 comp.unix.xenix:775

In article <135@sdti.UUCP> mjy@sdti.UUCP (0000-Michael J. Young) writes:
>In article <29699@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes:
>>Is it that malloc(3X) is buggy, or that it's SVID-compliant?
>No, it's buggy.  The core dumps come from within malloc(3x) itself.

That doesn't prove that malloc() is at fault -- if your application
has corrupted the arena block control headers that the malloc package
uses, then eventually malloc() or free() can die horribly.

However, it is true that every malloc implementation I've yet seen
has been non-portable, and some downright broken.  I thoroughly
overhauled malloc.c 1.5 in order to fix it for ports of my System
V emulation for 4.nBSD.  Perhaps some UNIX vendors, preferably AT&T,
should "buy back" the improvements.