For the C code below, compare the defintions of the int pointers a and b;
#include
#include
int main()
{
int *a=malloc(s
In C the cast is unnecessary. malloc
returns a void*
, and the C standard states:
A pointer to void may be converted to or from a pointer to any incomplete or object type. A pointer to any incomplete or object type may be converted to a pointer to void and back again; the result shall compare equal to the original pointer.
Further, K&R2 says:
Any pointer to an object may be converted to type void* without loss of information. If the result is converted back to the original pointer type, the original pointer is recovered. Unlike the pointer-to-pointer conversions discussed in Par.A.6.6, which generally require an explicit cast, pointers may be assigned to and from pointers of type void*, and may be compared with them.
A point may be made about C++ compatibility, as in C++ the cast is obligatory. However, IMHO this is hardly relevant, as idiomatic C++ calls for using new
instead of malloc
anyway.
Casting the return value of malloc()
is a C++ idiom and has no place in C code. It's only necessary when you want to compile the code as C++, which you shouldn't do as C and C++ are distinct languages with diffrerent semantics.
It only makes sense if you want to make a C library which defines inline functions in header files to be usable from C++. With the advent of link-time optimizations, this hopefully won't be necessary any longer as functions can be inlined even when defined in diffrerent source files.
As to people claiming explicit casting adds to readability, consider the given example
int *b=(int *)malloc(sizeof(int));
How exactly repeating the type THREE TIMES is more readable than
int *b = malloc(sizeof *b);
is beyond me.
C++0x even added type inference to get rid of similar repetitions, so I don't really think this is controversial.
The cast is not needed for the C language, but for C++ compatibility you may want to cast. This is one of the spots where C is not a subset of C++.
The following will compile in C but not C++:
int *a=malloc(sizeof(int));
The following will compile in both C and C++:
int *b=(int *)malloc(sizeof(int));
Is it better in any way to typecast the pointer of type void, returned by the malloc function?
Yes. It is clearer in meaning. It's the same reason I'd write
a = b + (c * d);
Now, I know the "()"s are not needed here, due to the rules of precedence of arithmetic operators, but they help me (and others) clearly see my intent.
$.02, etc. :)
-k
If we're talking C, best practice is to not cast the result of malloc()
. If we're talking C++, best practice is to use new
instead of malloc()
1.
The reason I recommend against casting the result is to avoid problems if you forget to #include
stdlib.h, or otherwise don't have a prototype for malloc()
in scope. Up until C99, if you had a function call with no prior declaration, the compiler would implicitly type the function call to return int
. Without the cast, this would result in an incompatible assignment warning. With the cast, the warning is supressed, and runtime errors could possibly result since the value returned from malloc()
would be converted from a pointer to an int and back to a pointer again, which is not guaranteed to be meaningful.
malloc()
to new
up front.void
, so malloc()
returned a char *
. Now, you needed to do the cast. Consequently the design pattern of casting malloc()
developed and influenced all the people who wrote the next set of code, and people are stilling reading those code bodies today and carrying the pattern forward. But C89 had void and so it's time to streamline the code.