malloc()

[Ray Butterworth]

> Well, what *is* the justification for adding "void *" to the language?  To
> allow people to shove pointers around without casts?  (Shudder!)  To make
> lint shut up about malloc()?  Or just to distinguish "generic pointers" from
> pointers that can be dereferenced?  (Could be done with a typedef.  So could
> "void", but they put it in anyway.)
> 
> I do not strongly object to the addition of "void *", but I am worried about
> its "hiding" errors.  (I'm one of those purists who thinks that programmers
> *should* use casts to change types.)  Also, it's a misnomer; it has nothing
> to do with "void".

When I first heard of (void*), I thought it was a wonderful idea.
malloc() and realloc() would return this type and it would be
guaranteed to be properly aligned and assignable to any other
type of pointer without complaint.  This much turned out to be true.

I also thought that casting anything into a (void*) would be a big
no-no.  Lint, and maybe even the compiler, would issue loud warnings
every time one tried to do this.  This wouldn't matter since normal
programs would never need to do it, and the warnings would only be
generated when malloc() and realloc() were compiled.  Unfortunately
this turned out to be false.

For some perverse reason that I have never been able to understand,
X3J11 decided that any pointer could be converted to (void*) without
complaint.  There was no need for this additional usage since the
standard also guarantees that any pointer may be correctly cast to
(char*).  It adds nothing useful and makes it much easier to code
undetectible errors.

(Lint complains too much about your code?  Don't worry, just change
all the pointers to void* and it will shut up.  (I assume you already
"#define CALL (void*)" and put CALL in front of all your function
calls so that you don't have to check any error statuses.)  Perhaps
lint should have an option which redirects all output to /dev/null?)