3 ms·

This might be a stupid question, but what are you meant to do if not cast malloc's return? My C is a bit rusty, but how else are you meant to allocate data of

This might be a stupid question, but what are you meant to do if not cast malloc's return? My C is a bit rusty, but how else are you meant to allocate data of different types on the heap?

scott_s 16y ago
C allows implict casting of void* to any other kind of pointer. Hence, you never need to cast the return from a malloc if you're storing it in a pointer. C++, however, does not allow this. So, if for some reason you're calling malloc rather than new in C++, you need to cast.
- sanderjd 16y ago
  You are not the poster who said "casting malloc's return is evil", so perhaps you don't agree with that statement, but I don't see how either of the points you make lead to the conclusion that it is "evil". You say that since void* is implicitly cast to all pointer types, you never need to explicitly cast it, but why would that make an explicit cast evil?
  - np3000 16y ago
    see http://c-faq.com/malloc/mallocnocast.html http://c-faq.com/malloc/mallocnocast.html
  - mfukar 16y ago
    An explicit cast of the result of malloc() can mask an error when you haven't included its proper definition in stdlib.h.
tptacek 16y ago
There's nothing wrong with returning void. There is something wrong with casting void. First, as someone else already pointed out, it can lead to an LP64 bug if you miss the declaration for malloc(), since int and caddr_t are not necessarily the same thing. But the bigger problem is that casting to void* basically tells the compiler "stop all further type checking". That's not a big deal if the token "malloc" on that line never changes, but, in real codebases, allocators get changed all the time. If you change from foo_alloc() to bar_alloc(), the compiler will rightly freak out when you try to assign a foo* to a bar. But that (void) construction explicitly prevents that check from occurring, thus turning what should be a compile-time error into a runtime error.

This might be a stupid question, but what are you meant to do if not cast malloc's return? My C is a bit rusty, but how else are you meant to allocate data of different types on the heap?

scott_s 16y ago

C allows implict casting of void* to any other kind of pointer. Hence, you never need to cast the return from a malloc if you're storing it in a pointer. C++, however, does not allow this. So, if for some reason you're calling malloc rather than new in C++, you need to cast.

sanderjd 16y ago
You are not the poster who said "casting malloc's return is evil", so perhaps you don't agree with that statement, but I don't see how either of the points you make lead to the conclusion that it is "evil". You say that since void* is implicitly cast to all pointer types, you never need to explicitly cast it, but why would that make an explicit cast evil?
- np3000 16y ago
  see http://c-faq.com/malloc/mallocnocast.html http://c-faq.com/malloc/mallocnocast.html
- mfukar 16y ago
  An explicit cast of the result of malloc() can mask an error when you haven't included its proper definition in stdlib.h.

tptacek 16y ago

There's nothing wrong with returning void. There is something wrong with casting void. First, as someone else already pointed out, it can lead to an LP64 bug if you miss the declaration for malloc(), since int and caddr_t are not necessarily the same thing. But the bigger problem is that casting to void* basically tells the compiler "stop all further type checking". That's not a big deal if the token "malloc" on that line never changes, but, in real codebases, allocators get changed all the time. If you change from foo_alloc() to bar_alloc(), the compiler will rightly freak out when you try to assign a foo* to a bar. But that (void) construction explicitly prevents that check from occurring, thus turning what should be a compile-time error into a runtime error.