gjohn@Neon.Stanford.EDU (George H. John) (02/25/91)
I'm having a problem porting source code from a unix machine to my mac. It seems that once I work out bugs caused by the difference in default integer sizes (2bytes mac, 4bytes unix) I'm having weird problems with malloc. For example, the following code doesn't work quite (er, at all) right: int *y; <printf *y gives garbage> y = (int *) malloc (sizeof(int)); *y = 5; <printf *y STILL gives garbage> If I replace the malloc with NewPtr, things work fine, but it doesn't seem right that the brilliant people at symantec would develop wonderful user interfaces and debugging tools and forget to write a working malloc(). What's up? I've repeated this problem on several machines. Thanks for any help, George John
n138ct@tamuts.tamu.edu (Brent Burton) (02/26/91)
Your code is perfect.
I have had this problem too. I don't know what it is, but I looked at
the alloc.c file and tried to figure it out. It's been a while, but I think
it returns null if it can't get the block and also if the block requested
is under a certain size. Don't quote me on this nor flame me, people.
What I did was to surround every malloc() call with this:
#ifdef THINK_C
x = (char *)NewPtr((long)sizeof(char));
#else
x = (char *)malloc(sizeof(char));
#endif
I also added this:
#ifdef THINK_C
#define free(x) DisposPtr((x))
#endif
This has relieved me of all problems. I'm going to, someday, examine the
THINK C code and try to fix it myself.
BTW, I did add the 4.02 patches.
+----------------------+--------------------------+
| Brent P. Burton | n138ct@tamuts.tamu.edu |
| Texas A&M University | Computer Science/Physics |
+----------------------+--------------------------+lindahl@violet.berkeley.edu (Ken Lindahl 642-0866) (02/26/91)
In article <12591@helios.TAMU.EDU> n138ct@tamuts.tamu.edu (Brent Burton) writes: >Your code is perfect. > >I have had this problem too. I don't know what it is, but I looked at >the alloc.c file and tried to figure it out. It's been a while, but I think >it returns null if it can't get the block and also if the block requested >is under a certain size. Don't quote me on this nor flame me, people. > >What I did was to surround every malloc() call with this: > >#ifdef THINK_C > x = (char *)NewPtr((long)sizeof(char)); >#else > x = (char *)malloc(sizeof(char)); >#endif > >I also added this: >#ifdef THINK_C >#define free(x) DisposPtr((x)) >#endif > >This has relieved me of all problems. I'm going to, someday, examine the >THINK C code and try to fix it myself. > >BTW, I did add the 4.02 patches. > +----------------------+--------------------------+ > | Brent P. Burton | n138ct@tamuts.tamu.edu | > | Texas A&M University | Computer Science/Physics | > +----------------------+--------------------------+ Ken Lindahl lindahl@violet.berkeley.edu Advanced Technology Planning, Information Systems and Technology University of California at Berkeley
lindahl@violet.berkeley.edu (Ken Lindahl 642-0866) (02/26/91)
Well, I guess everybody should have to apologize at least once for posting a blank followup, so here it is: I'm sorry. The fingers are faster than the brain, sometimes. In article <12591@helios.TAMU.EDU> n138ct@tamuts.tamu.edu (Brent Burton) writes: >Your code is perfect. So why doesn't it work? :-) >I have had this problem too. I don't know what it is, but I looked at >the alloc.c file and tried to figure it out. It's been a while, but I think >it returns null if it can't get the block and also if the block requested >is under a certain size. Don't quote me on this nor flame me, people. Well, I'm quoting you, but hopefully you won't think this is a flame. The original posting did not show the declaration for malloc() and this is critical. In Think C 4.0 and later, the correct declaration is void *malloc(); In Think C 3.x and in most UNIX implementations, the correct declaration is char *malloc(); I know from experience that if you try the latter declaration in Think C 4.x, you will get the behavior described above. The best way to get the correct declaration is to #include <stdlib.h> in any file containing invocations of malloc() or any of its friends(calloc(), free(), realloc(), ...). Ken Lindahl lindahl@violet.berkeley.edu Advanced Technology Planning, Information Systems and Technology University of California at Berkeley
cs483106@umbc5.umbc.edu (cs483106) (02/26/91)
In article <12591@helios.TAMU.EDU> n138ct@tamuts.tamu.edu (Brent Burton) writes: >What I did was to surround every malloc() call with this: >#ifdef THINK_C > x = (char *)NewPtr((long)sizeof(char)); >#else > x = (char *)malloc(sizeof(char)); >#endif >I also added this: >#ifdef THINK_C >#define free(x) DisposPtr((x)) >#endif I too have had problems with THINK C's malloc. I have taken the easy way out and simply ripped everything out of alloc.c, and replaced it with glue code to the Inside Mac equivalents. (I got too annoyed at doing a #define for every malloc I used!) I did the job about a month ago, It took me about an hour (I'm not all that great at 'asm' programming), and seems to be working great. actually, quite a bit of the original stuff can be used as examples of how to call NewPtr from an 'asm' directive. "Pope" Q.E.D Michael Kohne
steve@huxley.huxley.bitstream.com (Steve Stein) (02/26/91)
In article <12591@helios.TAMU.EDU> n138ct@tamuts.tamu.edu (Brent Burton) writes: > Your code is perfect. Wrong. > I have had this problem too. Because you make the same mistake, I think. The problem the original poster (to whom I replied by eMail) had was, I believe, that malloc was returning some strange values. I am virtually certain he was having this error because he forgot to #include <stdlib.h> like it says to in the friendly manual. Leaving this out has the effect of NOT declaring malloc before it's used. THINK C (like C compilers everywhere) will then assume that malloc will return an int, which in THINK C is a two byte value. This value will get sign-extended to a long when it is typecast to a pointer. This is not a problem on systems where sizeof(int)==sizeof(int *). SO: Lesson 1: Read the friendly manual. Lesson 2: Pay the syntax! - Steve Stein
jeffb.bbs@shark.cs.fau.edu (Jeffrey Boser) (02/26/91)
cs483106@umbc5.umbc.edu (cs483106) writes: > In article <12591@helios.TAMU.EDU> n138ct@tamuts.tamu.edu (Brent Burton) writ > >What I did was to surround every malloc() call with this: > >#ifdef THINK_C > > x = (char *)NewPtr((long)sizeof(char)); > >#else > > x = (char *)malloc(sizeof(char)); > >#endif > I too have had problems with THINK C's malloc. I have taken the easy way out > and simply ripped everything out of alloc.c, and replaced it with glue code > to the Inside Mac equivalents. (I got too annoyed at doing a #define for ever > malloc I used!) ahehm! listen up folks: THINK C Standard Libraries Reference, convieniently under malloc: #include <stdlib.h> void *malloc(size_t size); come on! if you do not include the header file, how can you expect it to work? .....Jeff
russotto@eng.umd.edu (Matthew T. Russotto) (02/26/91)
In article <5813@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: > > This is not correct. The original poster's problem is that he needs >to include the appropriate header file which contains the prototype for >malloc, namely <stdlib.h>. The problem is in code which assumes that pointers >and ints are the same size, and which therefore doesn't prototype a return-type >for malloc. The result is the returned pointer is invalid. Including <stdlib.h> >or adding a "extern char *malloc()" declaration will suffice to fix this >problem. > >R. > Rich Siegel Symantec Languages Group Internet: siegel@endor.harvard.edu > >"I was just trying to be subtle. That's my job, isn't it?" Wouldn't extern char *malloc(long); be better-- I have had at least as many problems messing up the parameter type-- if the return type is wrong at least you often get an error. (Of course, including the headers is the best way) -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
n138ct@tamuts.tamu.edu (Brent Burton) (02/26/91)
In article <STEVE.91Feb25153736@huxley.huxley.bitstream.com> <steve@bitstream.com> (Stephen Z. Stein) writes: >In article <12591@helios.TAMU.EDU> n138ct@tamuts.tamu.edu (Brent Burton) writes: >> I have had this problem too. >Because you make the same mistake, I think. > >I am virtually certain he was having this error because he forgot to > >#include <stdlib.h> >like it says to in the friendly manual. >Lesson 1: Read the friendly manual. >Lesson 2: Pay the syntax! Steve, (and others) this will get you everytime. I went and 'fixed' the code I modified -- removed the #defines and included <stdlib.h> and it worked. This is NOT a simple case of RTFM. I have -- it was "simple" oversight. Had I been thinking a little more, maybe I could've avoided it... :) Anyway, thanks to all who replied with a friendly reminder about <stdlib.h>. +----------------------+--------------------------+ | Brent P. Burton | n138ct@tamuts.tamu.edu | | Texas A&M University | Computer Science/Physics | +----------------------+--------------------------+
n138ct@tamuts.tamu.edu (Brent Burton) (02/26/91)
>ahehm! listen up folks: >THINK C Standard Libraries Reference, convieniently under malloc: >#include <stdlib.h> >void *malloc(size_t size); >come on! if you do not include the header file, how can you expect >it to work? automagically? +----------------------+--------------------------+ | Brent P. Burton | n138ct@tamuts.tamu.edu | | Texas A&M University | Computer Science/Physics | +----------------------+--------------------------+
kenk@tellabs.com (Ken Konecki) (02/27/91)
In article <1991Feb25.103404.3662@Neon.Stanford.EDU> gjohn@Neon.Stanford.EDU (George H. John) writes: >If I replace the malloc with NewPtr, things work fine, but it >doesn't seem right ... [to] forget >to write a working malloc(). Make sure you #include <stdlib.h>. I had problems with malloc too, and they magically went away when I included the stdlib.h file. Cheers, -Ken K -- Ken Konecki "Eat well, stay fit, and die anyway" e-mail:kenk@tellabs.com -or- ...!uunet!tellab5!kenk