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)