Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.unix.xenix
Subject: Re: smail2.5
Message-ID: <29699@sun.uucp>
Date: Thu, 1-Oct-87 14:25:19 EDT
Article-I.D.: sun.29699
Posted: Thu Oct  1 14:25:19 1987
Date-Received: Mon, 5-Oct-87 07:12:17 EDT
References: <398@auscso.UUCP> <132@sdti.UUCP>
Sender: news@sun.uucp
Lines: 20
Keywords: smail Xenix trouble
Xref: mnetor comp.unix.questions:4351 comp.unix.wizards:4618 comp.unix.xenix:873

> Gee, I guess Microport isn't the only AT unix to have a buggy malloc(3X)!
> Microport's fix for the problem is "use malloc(3C) instead."

Is it that malloc(3X) is buggy, or that it's SVID-compliant?  There are a
number of programs ("dc" comes to mind) that will compute the size of a block
of memory that they need and, even if it's zero, call "malloc" with that size.
The SVID specifies that this must return a NULL pointer, not a "pointer to a
zero-length block of memory" (in most, possibly all, implementations of
"malloc", you *can*, in a sense, get a pointer to a zero-length block of memory
- what "malloc" really allocates is a control header followed by the block of
storage, and the pointer it returns is to the first memory location after the
header).

Many C implementations will cause a program to bomb if it tries to use a NULL
pointer as if it pointed to something (I've even seen this on VAXes with UNIX
versions that provide a location 0, kids; attempts to *write* to low addresses
blow up, as this is part of the text segment).  Could this be the problem?
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com