🚀 go-pugleaf

>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