This is not "some systems" -- this is the result of trying to compile a C source file with a C++ compiler...

You're right.I'm developing an application with mixed C/C++ code and gather experience in solving such issues :-) Nevertheless I think the patch would make sense for devs like me, who copy&paste the code and then get strange compile errors.

I'll fix the commit log.

• chunk.memory = malloc(1); /* will be grown as needed by the realloc above */
• chunk.memory = (char )malloc(1); / will be grown as needed by the realloc above */

[Edit: I don't know what's up with Github's comment system, but it doesn't seem possible to quote a diff. The first line is a minus, the second a plus.]

This patch is in my opinion just wrong. In ANSI C the void pointer was introduced just so that the old K&R practice of always having to cast (among others) malloc could be disposed of. Worse, casting malloc can in some cases hide errors (I have an example of that stuck away somewhere).
malloc(3) is defined as "void *malloc(size_t size);" in <stdlib.h> so that it will match any type, that's the whole point.

-Tor

Interesting discussion here: http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc

I'm inclined to agree with @ptor here - the cast is entirely unnecessary in C.

And whilst I can't conjure up a reasonable circumstance where it would cause any harm, it's excess code for the sake of excess code, and More Code Is Bad.

If you're copy&pasting this into C++, then static_cast<char *> is the right way to do this not (char *)malloc(...

C & C++ are different, albeit related, languages. C is not a proper subset of C++. C++ is not a proper superset of C.

I too vote for not using the cast. We're using C, we don't need it. It is an example, it is important to keep it simple and easy-to-read.

Then let's close this issue.