bga@pnet51.orb.mn.org (Bruce Albrecht) (08/12/90)
According to the errata sheet, malloc is type (void *), and that it should
not be necessary to put a cast in front of the return value. However, when
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
outname, and I had to change it to (char *) malloc to get rid of the warning.
Am I misunderstanding something, or is the errata sheet wrong, or is there
something wrong with Lattice C (either in the include or compiler)?
Also, do I need to explicitly free any memory allocated by malloc before
the program exits, or does it get freed automatically? It looks to me as
though it is freed when the program terminates.
UUCP: {amdahl!bungia, uunet!rosevax, crash}!orbit!pnet51!bga
ARPA: crash!orbit!pnet51!bga@nosc.mil
INET: bga@pnet51.orb.mn.orgceej@pawl.rpi.edu (Chris J Hillery) (08/13/90)
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 >outname, and I had to change it to (char *) malloc to get rid of the warning. >Am I misunderstanding something, or is the errata sheet wrong, or is there >something wrong with Lattice C (either in the include or compiler)? 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 <a>my own dumb fault, which usually will crash if left in the code, or <b>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? >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
rosenber@ra.abo.fi (Robin Rosenberg INF) (08/13/90)
>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 >>outname, and I had to change it to (char *) malloc to get rid of the warning. >>Am I misunderstanding something, or is the errata sheet wrong, or is there >>something wrong with Lattice C (either in the include or compiler)? There is a small bug in one of the lattice include files where malloc and a few other functions have the wrong type, i.e char* instead of void*. It is either stdio.h or stdlib.h. Trying to include both of these files will give you an extern item attribute mismatch. Fix the file that is wrong. >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 <a>my own dumb fault, which usually will crash if left in the >code, or <b>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? Warnings should not be ignored. They are there to help you find bugs in your programs. You should check all warnings to see if it is a possible bug and if it is still correct rewrite it so the compiler gives you no more warnings. Type mismatches can be corrected with an explicit cast. Other warnings are more serious, like 'argument count incorrect', which is usually fatal. With Lattice C you can tell the compiler to issue an error message instead of a warning for certain warnings. ------------ Robin Rosenberg
dillon@overload.Berkeley.CA.US (Matthew Dillon) (08/14/90)
>In article <V%$%LR_@rpi.edu> 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 <stdlib.h> 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 <a>my own dumb fault, which usually will crash if left in the >code, or <b>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
root@bcstarc.stgt.sub.org (Frank Pecher) (08/14/90)
In article <3034@orbit.cts.com> bga@pnet51.orb.mn.org (Bruce Albrecht) writes: >According to the errata sheet, malloc is type (void *), and that it should >not be necessary to put a cast in front of the return value. However, when >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 >outname, and I had to change it to (char *) malloc to get rid of the warning. >[...] Which options did you use? I compiled with lc +L <prog> and got no warnings of any kind, and the executable worked ok. I have version 5.05, too. >UUCP: {amdahl!bungia, uunet!rosevax, crash}!orbit!pnet51!bga >ARPA: crash!orbit!pnet51!bga@nosc.mil >INET: bga@pnet51.orb.mn.org -- Frank -- Frank Pecher uucp: root@bcstarc.stgt.sub.org ==> (This line intentionally left blank) <==
zupke@mars.jpl.nasa.gov (Brian Zupke) (09/23/90)
In article <V%$%LR_@rpi.edu> 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); > >> [discussion of malloc deleted] In this case, the pointer mismatch can be eliminated by "casting" the malloc function to type char. For example: char *outname; outname = (char *)malloc(SomeConstant); >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) > [some stuff deleted] >Is my code less effcient or corrupt or something if I leave these? Howdy. My understanding is that type mismatches can make code less portable. Even though your programs work fine with these warnings, other compilers (having different size variables) may not. It is always best to explicitly state your intentions by use of type casting (see above). Also, if you simply ignore these warnings, then it different (possibly more serious) warnings can be "lost in the shuffle". And, of course, when using Manx C, they'll make an ERROR message scroll right off the screen. -Brian Test signature file.
peter@sugar.hackercorp.com (Peter da Silva) (09/23/90)
In article <1990Sep23.061925.6887@jato.jpl.nasa.gov> zupke@mars.UUCP (Brian Zupke) writes: > In this case, the pointer mismatch can be eliminated by "casting" the > malloc function to type char. For example: > char *outname; > outname = (char *)malloc(SomeConstant); But the underlying problem, that malloc() is declared as returning an int (by not being declared at all) still needs to be fixed. Try adding void *malloc(); somewhere in scope. You may still need to ast it, but at least your code will still work when (int) and (void *) are no longer the same size. (As an aside: most 68000 compilers I've used in the past have returned pointers in A0 and ints in D0. Seems like an obvious move. I guess Manx and Lattice had other priorities.) -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
fnf@riscokid.UUCP (Fred Fish) (09/25/90)
In article <6620@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >(As an aside: most 68000 compilers I've used in the past have returned > pointers in A0 and ints in D0. Seems like an obvious move. I guess Manx > and Lattice had other priorities.) It does seem obvious, but most of the compilers I've worked with that did so ended up being modified to copy the value from A0 to D0 just before returning, so that buggy programs (such as the one that started this thread) would continue to run without change. -Fred
dillon@overload.Berkeley.CA.US (Matthew Dillon) (09/26/90)
>In article <13660@mcdphx.phx.mcd.mot.com> fnf@riscokid.UUCP (Fred Fish) writes: >In article <6620@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>(As an aside: most 68000 compilers I've used in the past have returned >> pointers in A0 and ints in D0. Seems like an obvious move. I guess Manx >> and Lattice had other priorities.) > >It does seem obvious, but most of the compilers I've worked with that >did so ended up being modified to copy the value from A0 to D0 just before >returning, so that buggy programs (such as the one that started this >thread) would continue to run without change. > >-Fred This type of 'buggy' program is such an obscure bug that I fault the compilers for trying to do the A0/D0 business without adding appropriate cautions. For example, simply renaming any defined function that returns a pointer to something like p_<function_name> instead of _<function_name> would catch all such bugs at link time. Any compiler that returns pointers in A0 and NOT in D0 and does NOT do such renaming (or some other method to detect the problem) is screwed up. When I implement structural returns in my DICE compiler I will use the 'pass pointer to return storage and have callee dump structure through that pointer instead of the static storage return' method. To catch such prototype errors all routines that return structures will be silently renamed by the compiler, so any improperly prototyped call will generate a link error. I intend to do the same for prototyped functions that cause the size of arguments to be different from non-prototyped functions... again to catch any screwups on the programmer's part that would otherwise be difficult to debug. I like the idea of returning pointers in A0 instead of D0 and would use the same renaming convention to support it. By the way, malloc() is prototyped in <stdlib.h> as per ANSI standard in the Lattice, Manx, and DICE compilers. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
peter@sugar.hackercorp.com (Peter da Silva) (09/30/90)
> In article <6620@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >(As an aside: most 68000 compilers I've used in the past have returned > > pointers in A0 and ints in D0. Seems like an obvious move. I guess Manx > > and Lattice had other priorities.) In article <dillon.6198@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: > This type of 'buggy' program is such an obscure bug that I fault the > compilers for trying to do the A0/D0 business without adding > appropriate cautions. Why? Any program that fails on this sort of compiler will also fail on any compiler where sizeof(int) != sizeof(char *) (like Aztec C on the Amiga in default mode prior to 5.0, or any IBM-PC compiler with reasonably large programs). Far from being an obscure bug, it's by far the most common one in BSD/VAX originated software. If you want to play games with the name, why not put the *whole* prototype into the name? (frex, if you have (void *)malloc(unsigned), make the real name of the routine vp$malloc$u) -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.