Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!uflorida!usfvax2!jc3b21!crash
From: crash@jc3b21.UUCP (Frank J. Edwards)
Newsgroups: comp.sys.amiga
Subject: Re: what's wrong with this picture?
Message-ID: <642@jc3b21.UUCP>
Date: 25 Apr 89 04:41:54 GMT
References: <13853@louie.udel.EDU>
Organization: St. Petersburg Jr. College, FL
Lines: 62

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