When do I need to cast the result of malloc in C language?
This question already has an answer here:
For any implementation conforming to C89 or later, casting the result of malloc() is never necessary.
Casting the result of malloc() is mentioned in the Errata for The C Programming Language, Second Edition:
142(§6.5, toward the end): The remark about casting the return value of malloc ("the proper method is to declare ... then explicitly coerce") needs to be rewritten. The example is correct and works, but the advice is debatable in the context of the 1988-1989 ANSI/ISO standards. It's not necessary (given that coercion of void * to ALMOSTANYTYPE * is automatic), and possibly harmful if malloc , or a proxy for it, fails to be declared as returning void * . The explicit cast can cover up an unintended error. On the other hand, pre-ANSI, the cast was necessary, and it is in C++ also.
(That link is no longer valid. The late Dennis Ritchie's home page is now here; it points to an updated location for the home page for the book, but that link is also invalid.)
Best practice is to assign the result of a malloc() call directly to a pointer object, and let the implicit conversion from void* take care of type consistency. The declaration of malloc() needs to be made visible via #include <stdlib.h> .
(It's barely conceivable that you might want to use malloc() in a context where an explicit conversion is needed. The only case I can think of is passing the result of malloc() directly to a variadic function that needs an argument of a pointer type other than void* . In such an unusual and contrived case, the cast can be avoided by assigning the result to a pointer object and passing that object's value to the function.)
The only good reasons to cast the result of malloc() are (a) compatibility with C++ (but the need to write code that compiles both as C and as C++ rarer than you might expect), and (b) compatibility with pre-ANSI C compilers (but the need to cater to such compilers is rare and becoming rarer).
Firstly: K&R C is ancient.
Secondly: I don't know if that's the full code in that example, but in K&R C, functions are assumed to have an int return value if not otherwise declared. If he's not declaring that malloc , it means it returns int as far as the compiler is concerned, hence the cast. Note that this is undefined behavior even in C89 (the earliest standarized version) and extremely bad practice; but he may have done it this way for brevity, or perhaps due to laziness --- or maybe for some other historical reason; I don't know all the intricacies of K&R C, and it might be that void* to char* casts were not implicit back then.
I should add that this is a very serious problem, since int and void* may have different sizes (and often do --- the most common example being most x86_64 code, where pointers are 64-bit, but ints are 32-bit).
UPDATE: @KeithThompson has informed me that the code is from 2nd edition, and malloc is declared there. That one is (unlike 1st ed) still relevant, if very much outdated at places.
I'm guessing that the cast was likely done for compatibility with non-conforming compilers, which mattered at the time, as many [most?] compilers were not fully conforming yet. Nowadays, you'd have to get out of your way to find one that would need the cast (and no, C++ compilers don't count; they're C++ compilers, not C compilers).
People who want (or may want) to cross compile C and C++ often cast malloc(.) because C++ won't automatically promote void* .
As others point out in the good old days when function prototypes were optional the compiler would assume malloc() returned int if it hadn't seen the prototype with potentially catastrophic run-time outcomes.
I try to see some point in that argument but I simply can't believe such situations occur with a regularity that warrants the flaming people then get for casting malloc(.) .
Look at any Question that casts malloc(.) on this site and it doesn't matter what it's about some one will angrily demand they remove their casts as though they make their eyes bleed.
NB: It does no good and makes nothing wrong right to cast malloc(.) so it is clutter. In fact the only (real) argument I know is that it leads people to look at the cast and not look at the argument - which is what matters!
I saw code on here today:
int** x=(int**)malloc(sizeof(int)*n);
It's very easy to be lulled into a false sense of security. The sizeof(int) is doing (or in this case failing to do) the work to make sure what comes back from malloc(.) is right for the purpose. (int**) does no work.
I'm not saying cast it. I am appealing for calm. I certainly think if a novice is failing to call free(.) we teach them that lesson before we get into nuances of casting malloc(.) .