db@cbosgd.UUCP (Dave Bursik) (07/04/85)
I just tried using the malloc() supplied with the Aztec C68K commerical package and got unsatisfactory results. After computing the size of my array, I called malloc(), storing the returned value in a char *. My program acted rather strangely, apparently refusing to store anything in the array. On printing out the contents of the pointer variable, I found it was something like 0xfffff7b3 (in other words, off the end of the 512K address space). I tried using lmalloc() (the application heap version of malloc()), but got similar results (though the numbers were different). Has anyone else experienced similar difficulties? (Reply via mail. Thanks.) Dave Bursik/..cbosgd!db P.S. I got around the problem by switching to a fixed-size array (which I should have used in the first place since there was a manageable upper bound on the array size). =djb=
hamachi@ucbvax.ARPA (07/05/85)
From: hamachi (Gordon Hamachi) I've noticed exactly the same thing with Megamax C. It sure is the pits when something as funadmental as malloc screws up. One funny thing is that malloc works until your program grows beyond a certain size. You can store into malloc'ed locations by masking off the upper bits of the returned value, but that is the kind of horrible kludge that makes hackers run screaming into the night. Depending on how much memory you have, the number of bits to mask changes. Also, when you try to free one of these, the Mac is likely to crash. A better alternative is to use the toolbox calls and/or manage your own storage. --Gordon Hamachi