seiler@chrpserv.gsfc.nasa.gov (Ed Seiler) (10/30/89)
I seem to be having trouble when requesting blocks of memory using Think C 3.01. Checking things out with the debugger under Multifinder, it seems that when I make a request using malloc or calloc, the resultant blocks start at very high memory locations that are way out of the application zone, though everything seems to indicate that I am indeed in the application zone when the request is made. If I replace a call of malloc woth a call to NewPtr, (which is all malloc is supposed to do anyway) it works fine. Are there known bugs in Think C 3.01 memory allocation? Is there a fix in a newer version of Think C? Ed Seiler Goddard Space Flight Center Greenbelt, MD 20771 seiler@chrpserv.gsfc.nasa.gov
earleh@eleazar.dartmouth.edu (Earle R. Horton) (10/31/89)
In article <521@dftsrv.gsfc.nasa.gov> seiler@chrpserv.gsfc.nasa.gov (Ed Seiler) writes: >I seem to be having trouble when requesting blocks of memory using Think C >3.01. Checking things out with the debugger under Multifinder, it seems that >when I make a request using malloc or calloc, the resultant blocks start at >very high memory locations that are way out of the application zone, though >everything seems to indicate that I am indeed in the application zone when >the request is made. If I replace a call of malloc woth a call to NewPtr, >(which is all malloc is supposed to do anyway) it works fine. Are there known >bugs in Think C 3.01 memory allocation? Is there a fix in a newer version of Think C? Have you included the proper header file to declare malloc() as returning a long value? If you do not, then the compiler thinks that malloc() returns an int (short in Think C) and sign-extends the return value. Malloc() is not necessarily just in interface to NewPtr(). Many versions of malloc() include extra features such as caching of blocks that should increase performance over that of the raw system call. This may not apply to the Think C version, but it certainly applies to the version I use, which I copied directly out of K&R. Earle R. Horton