rudolph@m.cs.uiuc.edu (07/18/89)
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. This is all on a Plus with 1M and no multifinder, sys 6.0. I'm not experienced at Mac programming, but I am at 'C,' and I can't find anything wrong with what I'm doing, especially since it works under Unix. David Rudolph rudolph@m.cs.uiuc.edu University of Illinois
jkjl@cs.mu.oz.au (John Keong-Jin Lim) (07/19/89)
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 You gotta #include "storage.h". What is happening is that all functions return an int by default. So you are getting the high bits of your address only. Thus you get low memory addresses when using malloc (Talk about 32-bit clean !). john ps : #include "proto.h" might be even a better idea !
sdh@wind.bellcore.com (Stephen D Hawley) (07/19/89)
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."
jpd00964@uxa.cso.uiuc.edu (07/21/89)
> Are there any known problems with malloc, calloc, etc in LSC? > At first, malloc() was returning suspiciously low addresses (4 digit hex > numbers, so < 64K). I had a similiar problem. Make sure you are including stdio.h or it will give you an integer instead of a long as the return value. You can detect this because all of your values will be 16 bits or <64K. Better method is to just call NewPtr(); Michael Rutman Softmed
rudolph@m.cs.uiuc.edu (07/21/89)
Thanks to all who replied, here and by mail. Yes, I was so used to all the Unix machines, that I forgot int's were 16 bits on the mac, so I didn't declare 'char *malloc().' David Rudolph rudolph@m.cs.uiuc.edu University of Illinois
lehotsky@pmax7.osf.org (Alan Lehotsky) (08/16/89)
Regarding malloc returning suspicious addresses.... I'm not a betting man, but I'd wager $0.50 (try and collect) that you're calling malloc without having a proper prototype for malloc declared. It's been a while since I have used LSC and done Mac programming, but without the prototype, you're looking at register D0, not at register A0 - which is where pointers are are returned.
jpd00964@uxa.cso.uiuc.edu (09/08/89)
>/* Written 12:22 pm Aug 15, 1989 by lehotsky@pmax7.osf.org in uxa.cso.uiuc.edu:comp.sys.mac.programmer */ >/* ---------- "Re: malloc in LSC" ---------- */ > >Regarding malloc returning suspicious addresses.... > >I'm not a betting man, but I'd wager $0.50 (try and collect) >that you're calling malloc without having a proper prototype >for malloc declared. > >It's been a while since I have used LSC and done Mac programming, but >without the prototype, you're looking at register D0, not at register >A0 - which is where pointers are are returned. >/* End of text from uxa.cso.uiuc.edu:comp.sys.mac.programmer */ Worse, from personal experience, you are getting only 16 bits if you don't prototype it by including the correct .h files. That means that the high 8 bits (16bits on a Mac II) get zeroed. However, the original programmer should be calling NewPtr anyway, not malloc. Michael Rutman