Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!bellcore!wind!sdh
From: sdh@wind.bellcore.com (Stephen D Hawley)
Newsgroups: comp.sys.mac.programmer
Subject: Re: malloc in LSC
Message-ID: <17234@bellcore.bellcore.com>
Date: 19 Jul 89 15:39:33 GMT
References: <73300002@m.cs.uiuc.edu>
Sender: news@bellcore.bellcore.com
Reply-To: sdh@wind.UUCP (Stephen D Hawley)
Organization: Bellcore, Morristown, NJ
Lines: 70

In article <73300002@m.cs.uiuc.edu> rudolph@m.cs.uiuc.edu writes:
>Are there any known problems with malloc, calloc, etc in LSC?  I have a
>program that is basically Unix-style - the only Mac-type stuff is a call
>to SFGetFile.  When I call malloc(), I get strange results.  If I
>statically allocate the array, it works fine.  It also works fine using
>malloc() with the exact same code (minus SFGetFile) on a Unix machine.
>
>At first, malloc() was returning suspiciously low addresses (4 digit hex
>numbers, so < 64K).  When I wrote to these addresses, the Mac eventually
>crashed.  The I tried removing all my INITs, and it started returning
>ridiculously high address (8 hex digits starting with ffff).  Reading
>from these produced garbage.  I'm only trying to allocate about 500
>bytes at a time.

Ok, there are two possible problems, 1 may be yours, the other may be
Think's.

1) you are not declaring the return type of malloc():

Thing *
WatchMyStuff()
{
	Thing *Spot;

	Spot = malloc(sizeof(Thing));
	Spot.Kansas = Topeka;
	/*
	 * this will crash at this point, because I have not
	 * declared the type of malloc().
	 * If the code read:
	 * Thing *Spot;
	 * void *malloc();
	 * etc, it would probably work.
	 */
}

If you have the "check pointer types" option set, this error should be
trapped.  It is not uncommon for UNIX people to get bitten by this one
because in the UNIX world, generally sizeof(int) == sizeof(void *).  This
is not true on the Mac.  Since you're getting only 4 byte values, I would
suspect this.

The second problem is with Think's declaration of malloc()

void *malloc(size)
unsigned int size;
{
	return NewPtr(size);
}

The problem here is that NewPtr() takes an unsigned long as its argument, not
an unsigned int.  K & R claims the following about function calls:
"... any [arguments] of type char or short are converted to int; and as
usual, array names are converted to pointers.  No other conversions are
performed automatically; in particular the compiler does not compare the
types of actual arguments with those of formal arguments."

This means that NewPtr() is getting whatever happens to be on the stack in
the high word of size, UNLESS Lightspeed C performs the conversion for
pascal functions.  The manual says that this is true, but I had a program
that crashed spuriously, that relied on malloc() and free() heavily.  I
found that if I replaced all the calls to malloc() with NewPtr((long)size)
and free() with DisposPtr(ptr), the crashing vanished.
(This was with version 2.15 some time ago --haven't tried malloc since)

Go figure.

Steve Hawley
"1) Never get involved in a land war in Asia and 2) Never go in with a
Sicilian when death is on the line."