FAQ: Casting malloc?

[Simon]

Gday,

Just wondering, i have read a fair bit that you shouldn't cast malloc and i am just wondering what casting actually is e.g

from another post

example t=(char*)malloc(26 * sizeof(char));

prelude said not to cast malloc,

can someone explain what this casting is and how it has been done in this example. and what to do instead?

Thanks

[Fordy]

malloc returns a void pointer...what this means is that the return points to something, but that something could be more or less anything......so what you are doing above is giving a hint to the compiler that the data returned from malloc should be treated as a pointer to a char (or an array of chars).......

in std C, there's no need to cast from malloc, but of you are compiling your code as C++, it will give an error without the cast being present.....this is due to C++ being more type sensitive (it has to be due to its ability to define custom types)

[Salem]

casting is where you (the programmer) decide that you know better than the compiler.

So when you say this
(char*)malloc(10)

You're saying that you take whatever malloc returns, convert it to a char*, and assign that to the variable in question.

This is all well and good if malloc is prototyped properly (by including stdlib.h), where it's defined as returning void*.

The problem comes in when you fail to include stdlib.h, and the compiler initially assumes that malloc returns an int. The real problem is, you DONT get any warning from the compiler.

You merrily then convert that int to a char* (via the cast). On machines where sizeof(char*) is different from sizeof(int), the code is seriously broken.

Now if you just have
char *var = malloc( 10 );
And you miss out the include <stdlib.h>, you will get a warning from the compiler.

http://www.eskimo.com/~scs/C-faq/s7.html

[Simon]

so instead of this:

Originally posted by Simon

t=(char*)malloc(26 * sizeof(char));

which casts malloc as a char*,
you would be better to do this:

t=malloc(26 * sizeof(char));

???

[Salem]

> you would be better to do this:
In C, yes

But note Fordy's comments about C++

But in C++, you should be using the new operator to get more memory, not malloc

[Simon]

Thanks Salem,

Always Very Reliable.

[Dave_Sinkula]

I have a couple of comments. Let's start with this.

char *t=(char*)malloc(26 * sizeof(char));

As has already been discussed, the cast is something to avoid in C. It is a holdover from the pre-ANSI C days.
http://www.eskimo.com/~scs/C-faq/q7.7.html

So then we have the following.

char *t = malloc(26 * sizeof(char));

But it is useless to do sizeof(char) because it is always 1. So it could just as well be as follows.

char *t = malloc(26);

But I prefer the following instead.

char *t = malloc(26 * sizeof(*t));

Then if I need to change t to some other type, the code only needs to be changed in one spot.

long *t = malloc(26 * sizeof(*t));

Dwelling on this a little, I find that even sizeof(int) stands out as code to avoid. If you use sizeof on the object itself, you always get its correct size. If you use sizeof on the presumed type of an object, you will get the size of a presumed type -- which may or may not be the size of the object.

This may seem trivial for small amounts of code. But when project get bigger and changes are in multiple modules it can get confusing. I guess I just find it better to avoid the middleman and always be safe.

[JoeSixpack]

Whilst I agree with what has been posted, would I be correct in assuming that when/if C99 is widely supported, the benefit of not casting malloc for the reasons mentioned will be nullified because the standard forbids implicit function declaration? So that for normal coding, if you want the compiler to help you it may be preferable to type cast?

[Sayeh]

In the first place, there is nothing wrong with using type coercion. newbies call this 'casting'. All it does is help the compiler convert a returned type from one type to another type. And in fact, is necessary for code portability to older compilers and on some platforms.

As for lauding the C99 standard, be careful. Many things about the C99 standard are actually incorrect because they have been instituted by persons with too little knowledge and history in programming. In many cases obfuscating what was once obvious into something abstract.

When you say:

t = (int*) malloc(sizeof(int) * 200);

You are _not_ coercing a function, you are coercing its result. Once again, this is merely to get your logic (for whatever reason you want an int pointer) past the compiler's syntactics.

You must be smarter than your tools.

[nsbuttar]

Well a lot has been said on this topic instead of repeating these things i would like to tell something.

No reply has yet covered why we do type casting? what is the problem;

Lets say u allocate the following memory:

---------------------------------------------
code follows
----------------------------------------------
char *t;

t=malloc(10*sizeof(char));

-----------------------------------------------
Now u have to operate the memory provided to u one by one. So the compiler must know the size of one unit of data. Now the default value returned by malloc is void , though most of the compilers will adjust for it by looking at the LHS data type,but even then to avoid any undesireable and unintended affects we should tell the compiler about the data type. As malloc returns void it can be typecasted any data type. now when u will execute the following code
-------------------------
t++;
----------------------
the no of unit data types to skip to go to the next unit data type will depend upon what type of value is *t holding if we typecast the reurned data type by malloc to unsigned * it will skip 4 of if we typecast it to char * it will skip none;

[Dave_Sinkula]

Originally posted by nsbuttar
the no of unit data types to skip to go to the next unit data type will depend upon what type of value is *t

Very true.

Originally posted by nsbuttar
[...] holding if we typecast the reurned data type by malloc to unsigned * it will skip 4 of if we typecast it to char * it will skip none;

The cast of the return value of malloc is not at all relevant to incrementing a pointer. It is the pointer type that tells the compiler how many bytes to increment the pointer, not the manner in which the pointer was assigned its current value.

#include<stdio.h>
#include<stdlib.h>
#define WYSIWYG(x)   #x, (x)
int main(void)
{
   char *t = (int*)malloc(15), *copy = t;
   if(t)
   {
      printf("%s = %p\n", WYSIWYG(t));
      ++t;
      printf("%s = %p\n", WYSIWYG(t));
      free(copy);
   }
   return(0);
}
/* my output
t = 007A305C
t = 007A305D
*/

The pointer advanced neither none nor 4. It advanced the expected 1. Let's try that the other way around. I'd expect my pointer to advance sizeof(int), which is 4 for the following.

#include<stdio.h>
#include<stdlib.h>
#define WYSIWYG(x)   #x, (x)
int main(void)
{
   int *t = (char*)malloc(15), *copy = t;
   if(t)
   {
      printf("%s = %p\n", WYSIWYG(t));
      ++t;
      printf("%s = %p\n", WYSIWYG(t));
      free(copy);
   }
   return(0);
}
/* my output
t = 007A305C
t = 007A3060
*/

Yup. I see casting the return value of malloc as all cost and no benefit.

[Sayeh]

nsbuttar stated:

No reply has yet covered why we do type casting? what is the problem;

In fact, I did provide an answer to this question:

All it does is help the compiler convert a returned type from one type to another type

----

I will say it simpler so you understand. "type coercion" or "casting" is used solely to make the compiler see two different types of variable as the same thing, so long as they are the same size.

if you don't use coercion, you will get a 'type mismatch' warning/error, depending on the compiler.

This is a syntactic/grammar issue, not a C-language logic issue.

[quzah]

To make it simple to understand...

Think of a void pointer as a union that has reference to every single type of data you could ever possibly think of. Hehe.

Quzah.

[Nick]

Well look at this way. When you want to find the sin of int x do
you do sin(x) or sin((double)x). Both are correct and both
coerse the type. Use whatever
you think looks best. Not including stdlib.h is kind of non-issue.
Anyone using a c compiler without turning on warnings
for this should not be programming.

[JoeSixpack]

As for lauding the C99 standard, be careful

I wasn't lauding it, just pointing out its implications.

Yup. I see casting the return value of malloc as all cost and no benefit.

A possible benefit of casting would be that you ensure that you are using the correct pointer type. If you want a block of ints, casting the return type ensures that you can only assign the memory location to an int pointer (or that you should at least get some kind of warning, depending on your compiler).