Hacker News Reader

Comment by tptacek | Hacker News Reader

It may be undefined, but gcc accepts it without warning under -Wall and does exactly what you'd expect. Note that (a) casting malloc's return is evil, (b) casting malloc to void* is silly since it's declared returning void* already, and (c) casting malloc to void* so it can be received as a char* is also pretty goofy.

View on HN

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?

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.

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?

see http://c-faq.com/malloc/mallocnocast.html

An explicit cast of the result of malloc() can mask an error when you haven't included its proper definition in stdlib.h.

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.

Reply on news.ycombinator.com