granz@apollo.uucp (David Granz) (07/08/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). > >Dave Bursik/..cbosgd!db ---------------------------------------- >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 > You should check that you declared malloc to return a pointer type before you used it. ie: char *malloc(); If you didn't, then C assumed that malloc returned an integer (16 bits) and sign extended it for you! -- Dave Granz/ ...decvax!wanginst!apollo!granz
mike@smu (07/08/85)
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)