Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: arrays of pointers - NOVICE QUESTION!( Be forwarned ! )
Keywords: pointers, arrays
Message-ID: <1753@auspex.auspex.com>
Date: 6 Jun 89 17:21:29 GMT
References: <10971@orstcs.CS.ORST.EDU> <17882@mimsy.UUCP> <1170@draken.nada.kth.se>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 28

>Hmmm. I thought that malloc() returned an unsigned long. At least
>it does on the Motorola compiler from 1982 I use, under Unix sys V
>for M68k-based machines. Can anyone who has more knowledge than me
>clarify this point ?

"malloc" returns a "char *" on any valid C implementation.  It probably
happens that, on the implementation to which you refer, "unsigned long"
and "char *" have the same number of bits; however, this does not, of
course, make them equivalent.

The only ways in which I could see "malloc" returning an "unsigned long"
on the implementation of which you speak are if:

	1) they botched the documentation (*and* the "lint" library!)
	   horribly, and claim therein that it returns an "unsigned
	   long";

	2) the compiler in question returns integral values in, say, D0,
	   and pointer values in, say, A0, and "malloc" returns its
	   value in D0 - which means that they'd have had to tamper with
	   the vanilla S5 source, since said source defines it as
	   returning a "char *" (yes, I looked, and the source
	   *clearly* starts with "char *malloc(<argument>)", for both
	   versions of "malloc"), as well as botching the documentation
	   and the "lint" library.

I doubt that either one occurred, but if either did, the person
responsible should be shot.