mermelstein@inrs-telecom.uquebec.ca (Lois Mermelstein) (04/24/89)
Ok, I give up. Why does the following (example code for a doubly-linked-
list) give the compiler warning "pointer/int conversion"?
struct aet {
long x, y;
float xIncr;
struct aet *prev;
struct aet *next;
};
struct aet *head, *last, *this;
head = (struct aet *) malloc(sizeof(struct aet));
/* warning comes ^ here */
(Manx 3.6a, compiling with cc file, linking with ln file -lm -lc
[for the floating point numbers])
The main reason I'm asking is that the program keeps guruing (the "bad
address" one) in different places, suggesting something in the program
is writing on the code. Besides, it bugs me when code stolen straight
out of K&R, 2nd ed., produces compiler warnings.
Thanks much,
Lois Mermelstein
mermelstein@tel.inrs.cdn or
mermelstein@inrs-telecom.uquebec.caali@polya.Stanford.EDU (Ali T. Ozer) (04/25/89)
In article <13853@louie.udel.EDU> Lois Mermelstein writes: >Ok, I give up. Why does the following (example code for a doubly-linked- >list) give the compiler warning "pointer/int conversion"? > >head = (struct aet *) malloc(sizeof(struct aet)); Assuming you haven't declared malloc() explicitly anywhere, or included a header file that declares it, Manx assumes it returns an int (like any C compiler should). Thus coercion to a pointer generates the warning. Now, here's the bad news... Judging from your posting, you are using 16 bit ints, not 32. Thus Manx assumes malloc() returns a 16 bit entity which needs to be converted into a 32 bit one. Thus your pointer ends up losing the top 16 bits; you get an illegal pointer. Probably the reason for the guru. The solution is to include the following in your program: extern void *malloc(); And then do the coercion like you were. You will not get any warnings, and the program will not guru (in both 16 or 32 bit modes). Manx 5.0 will be ANSI, I hope... Ali Ozer aozer@NeXT.com
talmage@lti.com (David Talmage) (04/25/89)
> Ok, I give up. Why does the following (example code for a doubly-linked- > list) give the compiler warning "pointer/int conversion"? > struct aet { > long x, y; > float xIncr; > struct aet *prev; > struct aet *next; > }; > struct aet *head, *last, *this; > head = (struct aet *) malloc(sizeof(struct aet)); > /* warning comes ^ here */ I think I can answer this one. It just bit me last week. Try declaring malloc. Probably like this: extern char *malloc(); Without the declaration, your compiler probably thinks malloc() returns an integer. With that (struct aet *) cast, the compiler thinks you're trying to turn an integer into a pointer. David Talmage ------------------------------------------------------------------------------ David W. Talmage, Systems Programmer ...!{buita,bbn}!lti!talmage Language Technology, Inc. talmage%lti.uucp@bu-it.bu.edu 27 Congress St., Salem, MA 01970 (508) 741-1507
crash@jc3b21.UUCP (Frank J. Edwards) (04/25/89)
From article <13853@louie.udel.EDU>, by mermelstein@inrs-telecom.uquebec.ca (Lois Mermelstein): > Ok, I give up. Why does the following (example code for a doubly-linked- > list) give the compiler warning "pointer/int conversion"? > > struct aet { > long x, y; > float xIncr; > struct aet *prev; > struct aet *next; > }; > struct aet *head, *last, *this; > > head = (struct aet *) malloc(sizeof(struct aet)); > /* warning comes ^ here */ Try adding '#include <stdlib.h>' (or if Manx doesn't have that ANSI compatible file, use "<malloc.h>") before the first reference to malloc(). The problem is that without the being told what the definition of malloc() is, the compiler assumes "int". Then when you cast it to a pointer type, it generates the error. This is similar to a forward reference to a function which does not return int: main() { char *a; a = func1(); } char *func1() { ... } Most compilers will generate "redefined function" because of the first reference which caused of symbol of type int to be created, then later the compiler tries to make it a pointer to char. > The main reason I'm asking is that the program keeps guruing (the "bad > address" one) in different places, suggesting something in the program > is writing on the code. Besides, it bugs me when code stolen straight > out of K&R, 2nd ed., produces compiler warnings. > > Thanks much, > Lois Mermelstein > mermelstein@tel.inrs.cdn or > mermelstein@inrs-telecom.uquebec.ca Fixing this one won't get rid of your guru problem (or, at least, it's not likely :-) but you're right about the cause. Consider also that your stack could be corrupted, thus generating a bad return address during a function exit. (Embarrassing to admit, but this one has gotten me -- define a "char array[256]" and then use more than 256 elements!! This is usually after the code works though, and I'm going back changing constants to define's for portability's sake!? Oh well.) Good luck! ---- Frank "Crash" Edwards ...!uunet!pdn!jc3b21!crash
karl@sugar.hackercorp.com (Karl Lehenbauer) (04/26/89)
In article <13919@louie.udel.EDU>, talmage@lti.com (David Talmage) writes: > > Ok, I give up. Why does the following (example code for a doubly-linked- > > list) give the compiler warning "pointer/int conversion"? > > head = (struct aet *) malloc(sizeof(struct aet)); > > /* warning comes ^ here */ > I think I can answer this one. It just bit me last week. > Try declaring malloc. Probably like this: > extern char *malloc(); Netter Talmage is correct. People using small model (16-bit ints) can save themselves a lot of grief, and all of us can suppress the warnings, with a simple: #include <functions.h> ...at the start of every every C source file. P.S. Use AllocMem rather than malloc. -- -- uunet!sugar!karl | "Nobody hipped me to that, dude." -- Pee Wee -- Usenet BBS (713) 438-5018
Sullivan@cup.portal.com (sullivan - segall) (04/26/89)
>Ok, I give up. Why does the following (example code for a doubly-linked- >list) give the compiler warning "pointer/int conversion"? > [code deleted] > >(Manx 3.6a, compiling with cc file, linking with ln file -lm -lc > Unfortunately Manx isn't a very good replacement for lint. I would recommend including the <mem.h> file if you are going to use malloc. Otherwize your (manxified) 16bit Ints coming from malloc are going to get turned into 32bit pointers. And wheee! you start writing all over the first 64k of ram. >Thanks much, >Lois Mermelstein >mermelstein@tel.inrs.cdn or >mermelstein@inrs-telecom.uquebec.ca How I long for a good ANSI compiler... Anyone know when 5.0 is coming out? -Sullivan Segall _____________________________________________________________ /V\ Sully set the example: to fly without moving. We shall ' learn to soar on wings of thought. And the student will surpass the teacher. To Quote the immortal Socrates: "I drank what?" -Sullivan _____________________________________________________________ Mail to: ...sun!portal!cup.portal.com!Sullivan or Sullivan@cup.portal.com
jafo@hpfcdc.HP.COM (Sean Reifschneider) (04/27/89)
>P.S. Use AllocMem rather than malloc.
Tsktsk. How non-portable of you. AllocMem isn't good for EVERYthing.
Seanmermelstein@inrs-telecom.uquebec.ca (Lois Mermelstein) (04/27/89)
Aargh! Ok, I've been bitten by not declaring library functions properly before. Thanks to the probably 15 people who wrote back with the magic incantation void * malloc(); that *has* done the trick. I feel *real* stupid now, though...... Thanks again, Lois Mermelstein mermelstein@tel.inrs.cdn or mermelstein@inrs-telecom.uquebec.ca