Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.tech Subject: Re: malloc under Lattice C V5.05 Message-ID: Date: 13 Aug 90 23:17:33 GMT References: <3034@orbit.cts.com> Lines: 83 >In article ceej@pawl.rpi.edu (Chris J Hillery) writes: >bga@pnet51.orb.mn.org (Bruce Albrecht) writes: > >>I had defined the following fragment: >> char *outname; >> >> outname = malloc(SomeConstant); > >>the compiler gave me a warning that the malloc was not the same type as It sounds like you did not: #include malloc() is declared as returning a void * in this standard include file. >Here's a (sort of) related question: does it even matter if it gives you >a warning like this? Most cases when I get these warnings (type mismatch) >are either my own dumb fault, which usually will crash if left in the >code, or unimportant or outright intentional type mismatching (ie, >automatic type conversions for code efficiency). These programs have always >seemed to work right, even when I was given the warning (well, assuming it/ >they were the ONLY warnings/errors, of course); am I missing something? >Is my code less effcient or corrupt or something if I leave these? if sizeof(int) == sizeof(char *) (i.e. sizeof(int) == 4 on the Amiga), the generated code will work. The source is still not correct. You must at least declare the routine in question to return some kind of pointer. Here is an example: extern void *RemHead(); RIGHT struct Node *node = RemHead(list); extern struct Node *RemHead(); RIGHT struct Node *node = RemHead(list); extern char *RemHead(); WRONG, but not struct Node *node = RemHead(list); *too* wrong. (can be nearly safely cast'd) struct Node *node = RemHead(list); WRONG struct Node *node = (struct Node *)RemHead(list); VERY WRONG The last three examples show incorrect ways of doing things. The first results in a pointer-pointer mismatch which isn't too bad, but still wrong. Such can be fixed by casting the result. The second to last will result in a pointer-int mismatch which is definitely wrong... it only works if integers are the same size as pointers. Under the latest Lattice and Aztec compilers this is true so it will not crash the program, but it is not portable C. The last example is dead wrong. The routine still returns an integer, you are simply casting the integer into a pointer after the fact. So if the integer is 16 bits a 16 bit value will be exended into a pointer before the assign. Not only is this as non-portable as the second to last example, in many cases it will not even generate a warning message! (when porting to other machines and other compilers). >>UUCP: {amdahl!bungia, uunet!rosevax, crash}!orbit!pnet51!bga >>ARPA: crash!orbit!pnet51!bga@nosc.mil >>INET: bga@pnet51.orb.mn.org >-- > //..is|While 1 DO|Erin,Erin,where are|Art of Noise space| -- Ceej (= >\X/there| Fork; |you? /-----------.-^------------------|ceej@pawl.rpi.edu >AMIGAany|----------^-----|Cebhq gb or|Reclaimer:Hey!That's| gmry@mts.rpi.edu >(=other?|HOW DO YOU FEEL.|Yvoreny! (=|mine! Bring it back!|aka Chris Hillery -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA