FAQ: Casting malloc?

[JoeSixpack]

I fully understand your point, but it just doesn't help to cast malloc().

Then you don't fully understand my point.

You can't see the decalaration of temp but you know it's type. So if you happen to pass the wrong type to sizeof(), then what's the point in casting the return of malloc()?]

If you pass the wrong type to sizeof then you've allocated the incorrect amount of memory. So cast or no cast your in trouble (haven't we been here before). This has nothing to do with the point I'm making. If you know you want space for 20 int's how could you possibly pass the wrong type to sizeof()?

Yeah you could argue that you can just scroll up to temp's declaration, but then you'd never pass the wrong type to sizeof(), so what's your argument?

My argument is nothing to do with looking at temps declaration. In fact my argument is based on the assumption that the coder has been sloppy and not looked at temps declaration. My argument is based on the coder knowing the amount of memory they need (as stated, casting is never going to help there), and what type of pointer they want to use to manoeuvre around this memory, but then selecting the wrong pointer.

Casting doesn't help, in any way, IMO.

Look at my example and explain from what I've written there how casting wouldn't help. How casting wouldn't help prevent you making an incorrect assumption about the pointer type you're using? It currently has two bugs based on my false assumptions. If I had included casts these bugs would have been highlighted. So how does this mean casting doesn't help in any way?

[Prelude]

>Then you don't fully understand my point.
Allow me to take a stab at it. You are saying that the following code is wrong if I wanted to simulate an array of integers:

#include <stdlib.h>
/*
** my_header.h declares a to be a pointer to double
*/
#include "my_header.h"

int main ( void )
{
  a = malloc ( 24 * sizeof *a );

  return 0;
}

No warnings.

As it is the compiler implicitly converts the void pointer to a double pointer, the usage is correct, but not what you wanted. If, however, you had included a type cast to int * the compiler would likely give you a warning about incompatible types:

#include <stdlib.h>
/*
** my_header.h declares a to be a pointer to double
*/
#include "my_header.h"

int main ( void )
{
  a = (int *)malloc ( 24 * sizeof *a );

  return 0;
}

C:\C\C.c(9) : warning C4133: '=' : incompatible types - from 'int *' to 'double *'

This is a valid point, but so is the case for not using type casting. In the end, not using type casting is encouraged, but it is very largely a matter of style.

-Prelude

[The Dog]

Joe, after all that, I don't think that you understand your point.

Your point should've been, "It helps not to be a sloppy programmer!".

Then everything would make sense!

Nuff said already!

[Dave_Sinkula]

Originally posted by JoeSixpack
I don't want to discuss such things. Go and read K&R. Do they cast?? Or look for other gurus! They will tell you all the same.

Please Read
*Errata for The C Programming Language, Second Edition #142

More Gurus
void main() and cast to malloc
malloc question
Pointer Casts

[JoeSixpack]

Your point should've been, "It helps not to be a sloppy programmer!".

Perhaps.

Originally posted by JoeSixpack
I don't want to discuss such things. Go and read K&R. Do they cast?? Or look for other gurus! They will tell you all the same.

This wasn't my quote. I was replying to some-one who posted it.

By all means, post keep posting links. It doesn't alter the fact that it can be beneficial to cast the return value of malloc. Also I stated this in the context of using a C99 conforming compiler (right back at the start of the thread). The reason often given (and is in a few of the links you've posted) for not casting malloc is the possible implicit prototype problem. This is no longer a problem if the compiler doesn't allow implicit prototypes.

[Dave_Sinkula]

Originally posted by JoeSixpack
This wasn't my quote. I was replying to some-one who posted it.

My apologies for the misquote.

Originally posted by JoeSixpack
By all means, post keep posting links.

Okay, one more. But I give up.
http://groups.yahoo.com/group/c-prog/message/12179

[JoeSixpack]

That link is just rehashing what's already been posted here. It doesn't stop you making an error in the assumption as to what the pointer type is (you could falsely assume that ptr3 pointed to a foobar2).

foobar *ptr3;
/*lots of code*/

/*I now want 20 foobar2's
but make an error in my assumption
as to the type of pointer ptr3 is
and through my stupidity assume
that it has been declared to point
at a foobar2s*/
ptr3 = malloc (20*sizeof(*ptr3));

/*casting the return value of malloc
above would have explicitly told the compiler
what I was trying to do, and made it
scream at me. Therefore the method
used above is less robust*/

Also, the poster in your link complaining about all the cutting and pasting needed has presumably not heard of macros.

But I give up.

So do I . Probably.

[Shade]

It's funny to read...

I think noone will change their minds, so why discussing?

I (and as I see some others) keep doing it like the gurus, and you JoeSixpack keep casting.

I have learned that it is possible to program in a different style as the gurus, but I got to know, that it is somehow easier when you do what the gurus tell you

[JoeSixpack]

I think noone will change their minds, so why discussing?

Change someones mind about what? I'm not trying to convince people that they should always cast the return value of malloc; just pointing out that it can be benefical in some situations. My example showed that by using casting two bugs could have been avoided. This wasn't my opinion. It was a fact.

I (and as I see some others) keep doing it like the gurus, and you JoeSixpack keep casting.

I have learned that it is possible to program in a different style as the gurus, but I got to know, that it is somehow easier when you do what the gurus tell you

That's a really intellitgent pov, Shade. As I said above I'm not trying to convince anyone that they should cast the return value of malloc. My initial post was a question, hoping to start a debate on the subject. Not provoke mindless guru fanboyism such as that demonstrated by you among others. If you'd like to point out why casting is a bad thing in the context of the example I gave, then I'm all ears (or eyes). Otherwise you're contributing nothing.

[Sayeh]

I had to reinvolve myself with this-- this thread is an absurd example (yet again) of people becoming lost in the syntax issues of a language or a compiler, rather than being able to see beyond such things and get to the fascination of the logic.

Get's old, doesn't it.

-------------------------------------------------------------
To JoeSixPack:

I have yet to see any justifyable advantage to casting.

It has nothing to do with advantages or disadvantages. This is the wrong point of view. Stop thinking it is right or wrong. Type coercsion was developed for one reason and one reason only--

To resolve type mismatches at the preprocessor level. type coercion has nothing to do with execution.


---------------------------------------------------------------
To the rest of you:

If JoeSixPack wants to write all his code without ever using coercion-- fine. More power to this person.

We've listed what coercion/casting is for. It's a tool, nothing more. I prefer to utilize all my tools, rather than taking the extreme stance that 'tool x is good for nothing' or 'you should never use tool z'.

Keep on programming

[JoeSixpack]

*Joe Sxpack bangs his head violently against the wall*

this thread is an absurd example (yet again) of people becoming lost in the syntax issues of a language or a compiler, rather than being able to see beyond such things and get to the fascination of the logic.

Actually, all this thread has seemed to demonstrate is peoples inability to read.

And that, is timeless. Nice misquote, btw.

[master5001]

First off I would like to point out to everyone that says "don't type cast malloc()" that just because you don't need the type cast doesn't you shouldn't. malloc(), calloc(), and realloc() are part of the standard C memory manager. Check this out:

int *i = malloc(1);

This will return a pointer to a block of memory that is not big enough to accomodate the size of an int.

int *i = (int *)malloc(1);

This code still erroneous. So therefore I do not understand why people take issue with the cast (which is meaningless) if the only provision here is compatibility with older compilers. I did take note that syntax can be an issue with some compilers, however, a compiler that gives you grief over simple code such as this is not not a great compiler. If you look through my code you will always see a cast in front of all my mallocs, callocs, and reallocs only out of habbit. This is an issue of personal opinion.

[quzah]

int *i = malloc(1);

And like the other absurd example given for reasons to typecast, only a fool would do this. And, just like the other example, there is no point to type casting this mistake, because with or without the typecast, you still end up with incorrect code and the type cast has no effect what so ever. Neither one produces an error. Neither one produces a warning. Neither one will fix your broken code. Like I've said: There is no reason to ever cast malloc. The only remote examples provided are so absurd they'd never happen in real life, or if they did, they'd happen by a total novice coder who wouldn't benifit either way from the cast, or without it.

Quzah.

[pnxi]

By the way, can any body expain how to use realloc() function, and it is better to use a example.
Thanx for help!

[Fordy]

Originally posted by pnxi
By the way, can any body expain how to use realloc() function, and it is better to use a example.
Thanx for help!

Try a search