Malloc() function in C -- returns void or character pointer?

Question

I've been learning about the free store and heap memory and what not, and I've got two books telling me two different things. One is telling me that the malloc() function returns a void pointer (note: this book has been wrong before) and the other is telling me that it always returns a character pointer. Which is correct? Thanks!

Answer 1

Tron55555 wrote:
when you say "if it's declared as returning a char pointer", are you referring to a theoretical scenario with a different compiler that has declared malloc as returning a char pointer instead of a void pointer? Do I have your meaning right?
Yes. I think void* is standard, but I recall seeing it declared otherwise. The runtime library is written by programmers and a little time spent in this forum should convince you that programmers don't always agree on what's correct.
This seems to be the case with Xcode, right?
Yes. That's why I referred you to the manual page from the Darwin layer. The manual installed there should reflect the current version of gcc, which is the C compiler under Xcode. From the occasional unfortunate experience, we also know that "should" doesn't always equate to "is". But just use that manual and you'll do fine.
Until I read about this in my other book, I never used casts with the malloc function and it always worked fine. Do you think it would be good programming practice for me to get used to writing the function with a cast in case I ever come across a compiler that requires it? I mean it couldn't hurt to write it that way right, even if I am using a compiler that declares malloc as returning a void pointer and doesn't require a cast?
This is more a question of programming style. Type casts turn off the compiler's type checking. So in most cases, type casts are to be avoided. In the case of malloc, everyone knows the game, so an optional type cast depends on what you consider good style. The goal of all the style rules, from indenting to commenting, is to make it easy for someone else to read your code and understand it well enough to make a required change. So we ask ourselves, "What would I like to see 10 years from now when I won't even believe I wrote this stupid code?".
\- Ray
p.s.: Et's excellent point about byte alignment is a wonderful example of how a type cast can get you on the fast track to trouble. Casting a pointer returned from malloc is fine. But casting a pointer after it's been used could cause a problem. Byte alignment in this case means that an int can't start on an odd numbered memory location (I think it might need to be an address divisible by 4 on a 32-bit machine, but that's an Et question--especially as he's responsible for adding the subject of byte alignment to your thread). - R