malloc()

[guy at sun.UUCP]

> 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.

The key word here is "warnings".  The X3J11 standard doesn't say what
constructs may not give warnings; it merely states what is and isn't legal
C.  As long as the compiler produces code for it, X3J11 doesn't care how
many complaints it puts out.

Maybe C should be stricter about types (I think so), but it's too late for
that.

> This wouldn't matter since normal programs would never need to do it...

Well, err, umm, "void *" is also useful for declaring objects used by
several different modules, where each client of the object's implementation
wants to store some private data in the object, and you can't get away with
statically restricting the class of modules using this object.  Dennis
Ritchie's "streams" article in the BSTJ gives an example of this.  A "queue"
has pointers to "put" and "service" procedures, and a "void *" which
provides private storage for those procedures.  Replacing that "void *" with
a "struct tty *", or a union of similar structures, would be ridiculous.
Yes, you can't rely on the type system to check correctness.  (Maybe
something like Goedel's Incompleteness Theorem applies, where any type
system strong enough that all programs written using it are "correct" is
incomplete, in that there exist interesting and meaningful programs which
cannot be written within this type system?)

> For some perverse reason that I have never been able to understand,
> X3J11 decided that any pointer could be converted to (void*) without
> complaint.

No, they just decided that it could be so converted in a legal C program.
Appendix E.3 gives a list of warnings which many implementations might give;
the situations listed are all legal C, but may not be desirable C.

> (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?)

If you're worried about programmers trying to spoof "lint" you'd better find
some way of preventing them from hiding all dubious code inside "#ifdef
lint".  C is not guaranteed to work in an environment where you have to ride
herd on programmers.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.arpa