Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.5 $; site smu
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!inuxc!pur-ee!uiucdcs!convex!smu!mike
From: mike@smu
Newsgroups: net.micro.mac
Subject: RE: malloc() problems
Message-ID: <20800017@smu>
Date: Mon, 8-Jul-85 13:16:00 EDT
Article-I.D.: smu.20800017
Posted: Mon Jul  8 13:16:00 1985
Date-Received: Thu, 11-Jul-85 04:56:00 EDT
Lines: 30
Nf-ID: #N:smu:20800017:000:1349
Nf-From: smu!mike    Jul  8 12:16:00 1985


I have been using Megamax C for some time and in fact have been
working for Megamax recently.  There is nothing wrong with malloc(),
at least not so far as I can tell.  I imagine the same is true of
Aztec C.

The most likely problem with supposedly bad malloc() calls is that the
program does not contain a declaration like

	extern char *malloc();

If the declaration is missing, the compiler assumes that the function
returns int.  An int (at least under Megamax C) is a signed
sixteen-bit quantity.  What happens when signed integers are
extended to thirty-two-bit pointers?  Right!  The upper sixteen bits
of the pointer are destroyed by an EXT instruction.

I know that this is a common problem with Megamax C users, because
I've sat next to the technical support people and listened to the above
instructions given to five or six people a day.  While I'm at it, I
should mention that another common problem lies in the
misunderstanding of the meaning of a pointer.  It seems that a common
practice is to declare a char pointer to be used to hold some string
returned from a ROM routine, and then use the pointer as if it were an
array; that is, as if space had been allocated for the pointer!
Probably three out of five technical support problems stem directly
from this error among Megamax users.

Mike McNally
mike@smu  (...convex!smu!mike)