Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!apple!rutgers!umn-d-ub!umn-cs!thelake!steve
From: steve@thelake.mn.org (Steve Yelvington)
Newsgroups: comp.sys.atari.st
Subject: Malloc() vs. malloc() (was Re: dissassembly)
Message-ID: <0016901058160832@thelake.mn.org>
Date: 16 Jan 90 16:58:16 GMT
References: <F39D2F69C99FC014B9@UBVMS.BITNET> <1534@cs.rit.edu>
Organization: Otter Lake Leisure Society (White Bear, Minnesota, USA)
Lines: 52
X-Member-Of: STdNet, the ST Developers' Network


[In article <1534@cs.rit.edu>,
     ajy2208%ritcv@cs.rit.edu writes ... ]

> I have Mark Williams C, and am curious:  What is the difference between
> malloc() and Malloc() ????  

Malloc() is a macro that expands to direct invocation of GEMdos function
0x48. GEMdos Malloc() is broken in several ways that *probably* won't bite
you for what you're doing. (Some of these "pecularities" are documented in
the MWC manual.) However, it's not as safe as malloc().

malloc() is a library call. Like Malloc(), it returns a pointer to a block
of memory, or NULL. However, it does not directly call Malloc(). Instead,
it is part of a complicated package of memory management code that Mark
Williams Co. has written to work around the known bugs in the GEMdos
Malloc() function. Each C vendor has had to implement such a scheme.

> I am writing a slideshow/picture viewing
> program, and when I used malloc() to get a 32k block of memory for a
> picture, the picture always had some stray data at the top (looked
> suspiciously like the other variables I was using)..  However, when I
> used Malloc() this disappeared.  Boy, I almost pulled my hair out
> trying to figure out what was wrong!!!

Remember that malloc() is not required to clear garbage from the memory
block to which it points. If you need it cleared, use calloc() or clear
the block manually.

If MWC's malloc() is indeed pointing you to memory that is in current use
for some other purposes, it's broken -- but I doubt that actually is
happening. MicroEMACS would die horribly. It's the malloc() torture test
from hell.

Also, remember that you must point physbase to a 256-byte boundary (on the
ST, apparently not on the STE), or strange things may happen:

	char *ptr, *pbase;

	if (((*ptr = malloc(1024*32)) == NULL))
		panic();	/* allocation error */
	pbase = ptr + (ptr % 256);
	
... then call Setscreen(). (Note that I'm mallocking 32 kilobytes, while
the screen occupies only 32,000, so the pointer arithmetic is legal.)

-- 
   Steve Yelvington at the (thin ice today*) lake in Minnesota
   UUCP path: ... umn-cs.cs.umn.edu!thelake!steve
   
   *16 cars through the ice so far this year! Yes, you, too, can
    have that sinking feeling....