malloc()

Guy Harris guy at sun.uucp
Thu May 15 05:36:49 AEST 1986


> I saw the need for a "ALIGN *" datatype, and was hoping "void *" would
> be it.  (Nope, just a useless synonym for "char *").  The idea would
> be that, just as it's always legal to cast any pointer into a "char *",
> it would be legal to cast *from* "ALIGN *" to any pointer.  Then lint
> would shut up about malloc()!

No, you just don't understand how it works.  From the August 11, 1985 C
standard draft:

	C.2.2.3 Pointers

	   A pointer to "void" may be converted to a pointer to an
	object of any type.  A pointer to an object of any type may be
	converted to a pointer to "void" or to a pointer to an object
	of less strict alignment and back again without change.

Nowhere is it implied that "void *" is a synonym for "char *".  "lint"
should not give any complaints about conversions between pointers of other
types and pointers to "void" (this isn't stated in the C draft, but then
again it's not a description of "lint", it's a language standard).  As such,
it is not a synonym for "char *", since "lint" should (and does) complain
about conversions between "char *" and other pointers.  As the C draft
clearly states, it is legal to cast *from* "void *" to any pointer; as such,
if "malloc" is declared to return "void *", "lint" will shut up about it.

No, the language does not *guarantee* that a "void *" is properly aligned,
but there's no way for it to do so anyway.  Big deal.  The language couldn't
*guarantee* that an "ALIGN *" is properly aligned either - if you wrote
"malloc" in C (as all UNIX implementations I know of are written), you would
just have to trust that the implementation delivers a maximally-aligned
pointer.  As such, "ALIGN *" is just a useless synonym for "void *".

> Also, having malloc() return a real "ALIGN *" would be convenient for word-
> addressible machines where "char *" requires extra bits.

Maybe, but I'm not sure the added convenience of having "malloc" be able to
return a value of a type requiring fewer bits is sufficient to justify
adding another type to the language.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.arpa



More information about the Comp.lang.c mailing list