David_Anthony_Guevara@cup.portal.com (12/07/89)
I have a very novice Mac programming problem. I wrote a program for
a C class I'm taking that uses linked lists. The program runs fine
on my VAX at work, but when I run it on my Mac under TC 4.0, it gets
"lost". My question(s) is(are): When you use malloc to create a
node (ex: head = (struct linked_list *) malloc (sizeof( ELEMENT ));)
does the memory allocated come from the stack or the application heap?
I believe my problem is that the Mac is relocating my pointers and the
program just drops into a black hole. No bomb, but it just sits there
until I reset the system. If the storage is allocated from the application
heap, how can I make sure that nothing gets moved while the program is
running? I'm not using any toolbox calls, should I be? As I said, the
program DOES run on my VAX without any difficulty. My configuration is
a Mac Plus w/4Mb RAM, Think C 4.0, System 6.02 with assorted inits and cdevs.
Thanks for any help you can give me!
Dave Guevara,
Internet: guevara@fsd.arc.nasa.gov
guevara@fsdvx2.arc.nasa.gov
David_Anthony_Guevara@cup.portal.com
vallon@sboslab3.CS.SunySB.EDU (Justin Vallon) (12/08/89)
In article <24770@cup.portal.com>, David_Anthony_Guevara@cup.portal.com writes: > [Porting an application from Vax to Mac] Questions: > When you use malloc to create a > node (ex: head = (struct linked_list *) malloc (sizeof( ELEMENT ));) > does the memory allocated come from the stack or the application heap? Application heap. Otherwise, it would be deallocated when the function returns. > I believe my problem is that the Mac is relocating my pointers and the > program just drops into a black hole. Nope. Malloc calls NewPtr, which will never relocate a block of memory that it returns. See Inside Mac chapter on the Memory Manager. > No bomb, but it just sits there > until I reset the system. If the storage is allocated from the application > heap, how can I make sure that nothing gets moved while the program is > running? It wont. See above. > I'm not using any toolbox calls, should I be? No, you don't have to if you want to write a C (Object-C?) program. The Mac interface libraries make TC as close to "real" C as possible. > As I said, the > program DOES run on my VAX without any difficulty. My configuration is > a Mac Plus w/4Mb RAM, Think C 4.0, System 6.02 with assorted inits and cdevs. > Thanks for any help you can give me! Sorry that I couldn't give you any good news, but the problem must be in you program. Actually, one problem that I have a lot of times is forgetting that malloc takes a long (32-bits). ThinkC assumes an int (16-bits) if no prototype is given. See if malloc is being declared as malloc(long), or put it in yourself: Ptr malloc(long); If that doesn't help, then feel free to send me mail directly. > Dave Guevara, > Internet: guevara@fsd.arc.nasa.gov > guevara@fsdvx2.arc.nasa.gov > David_Anthony_Guevara@cup.portal.com -Justin vallon@sbcs.sunysb.edu
oster@dewey.soe.berkeley.edu (David Phillip Oster) (12/08/89)
In article <24770@cup.portal.com> David_Anthony_Guevara@cup.portal.com writes: >My question(s) is(are): When you use malloc to create a >node (ex: head = (struct linked_list *) malloc (sizeof( ELEMENT ));) >does the memory allocated come from the stack or the application heap? Neither. malloc allocates its storage out of big blocks that it gets from the Mac operating system by doing a NewPtr() system call. This is clear from the manual. >I believe my problem is that the Mac is relocating my pointers and the >program just drops into a black hole. The mac never relocates pointers. It only relocates handles, and you can't get a handle without specifically asking for one. To debug a program, set a breakpoint at a point you _know_ it reaches. (It always reaches the beginning.) Single step, looking at data structures as appropriate, until you get to the problem. Reapeat as necessaary until you understand enough about the problem to solve it. You need to think, you need to read the manuals, and you need to be observant. > The mac is a detour in the inevitable march of mediocre computers. > drs@bnlux0.bnl.gov (David R. Stampf) --- David Phillip Oster -master of the ad hoc odd hack. Arpa: oster@dewey.soe.berkeley.edu Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu
dks@shumv1.uucp (D. K. Smith) (12/08/89)
From a novice to a novice: I was recently using the TC and their unix shell environment to write a program for school. My bug was due to some arithmetic I was performing to calculate the address of my next struct member. If you are doing a "straight" list implementation then this is probably not your problem. (but in the event it relates...) The thing that tripped me up was my cast of the pointer before I did the math on it. I cast it as unsigned when it should have been unsigned long. (i.e. the top of my l.word was being chopped off.) The symptom to this problem was a linked list going ALL OVER THE PLACE. Hope this helps... if it doesn't, oh well. dk smith__________________________________________________________
sam@neoucom.UUCP (Scott A. Mason) (12/12/89)
Actually the fix may be very simple. I had a similiar problem when porting
some code from an (yuck) MeSsy-DOS program.
I finally found out that Think C happily lets me compile a program with
(x)alloc calls in it without the library included, but does strange things
with the pointers allocated.
The moral of this story is:
ALWAYS #include <storage.h>
or similar include to make sure (x)alloc is used from the library.
--
--------------------------------------------------------------------------------
"If it ain't broke, don't fix it," and certainly don't blame me.
UUCP: {pitt,scooter,hal,cwjcc,aablue}!neoucom!sam INTERNET: sam@neoucom.EDU
Scott A. Mason, Coordinator of Systems Operations, NEOUCOMsiegel@endor.harvard.edu (Rich Siegel) (12/14/89)
In article <1856@neoucom.UUCP> sam@neoucom.UUCP (Scott A. Mason) writes: >Actually the fix may be very simple. I had a similiar problem when porting >some code from an (yuck) MeSsy-DOS program. >I finally found out that Think C happily lets me compile a program with >(x)alloc calls in it without the library included, but does strange things >with the pointers allocated. This is a common problem when porting C code from systems where sizeof(int) == sizeof(char *), because standard C assumes that a function which is called before it is prototyped (or before its definition is encountered) returns an int as its result. In THINK C, libraries are added to the project; the #include directive merely includes any necessary macros and prototypes. If you don't wish to #include <storage.h>, you can insert a line like char *malloc(); which will serve adequately as a prototype. R. ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "When someone who makes four hundred and fifty dollars an hour wants to tell you something for free, it's a good idea to listen." ~~~~~~~~~~~~~~~
vallon@sboslab10.cs.sunysb.edu (Justin Vallon) (12/16/89)
In article <3427@husc6.harvard.edu>, siegel@endor.harvard.edu (Rich Siegel) writes: > In article <1856@neoucom.UUCP> sam@neoucom.UUCP (Scott A. Mason) writes: > >Actually the fix may be very simple. I had a similiar problem when porting > >some code from an (yuck) MeSsy-DOS program. > >I finally found out that Think C happily lets me compile a program with > >(x)alloc calls in it without the library included, but does strange things > >with the pointers allocated. > > This is a common problem when porting C code from systems where > sizeof(int) == sizeof(char *), because standard C assumes that a function > which is called before it is prototyped (or before its definition is > encountered) returns an int as its result. > ... > If you don't wish to #include <storage.h>, you can insert a line like > > char *malloc(); Isn't the problem also that malloc also accepts a long size? When I started programming in C using toolbox calls, the biggest problem that I had was forgetting to #include <MemoryMgr.h>, and Think C would assume that Handle NewHandle(long) was actually int NewHandle(int). The int would be passed, but NewHandle needed a long, it took my two bytes, and another extra two from just above the parameter, and I kept getting out of memory errors (when allocating 20 bytes), and I'd get a NULL handle. I don't know if the same problem applies to malloc, but I'd assume that it probably does. You should probably put char *malloc(long); as a prototype. I also found that "Require Prototypes" solves almost ALL of these type problems. > ~~~~~~~~~~~~~~~ > Rich Siegel > Internet: siegel@endor.harvard.edu > UUCP: ..harvard!endor!siegel > ~~~~~~~~~~~~~~~ -Justin vallon@sbcs.sunysb.edu