Xref: utzoo comp.std.c:1857 comp.lang.c:22974
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!amgraf!cpsolv!rhg
From: rhg@cpsolv.UUCP (Richard H. Gumpertz)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: commom malloc/free practice breaks standard - author strikes back
Message-ID: <416@cpsolv.UUCP>
Date: 17 Oct 89 14:40:42 GMT
References: <1989Oct16.111059.3840@anucsd.oz>
Reply-To: rhg@cpsolv.uucp (Richard H. Gumpertz)
Organization: Computer Problem Solving, Leawood, Kansas
Lines: 50

1) It seems to me that the UNUSUAL implementation of malloc is OK by the
current standard.

2) The standard is NOT meant to protect the compiler implementor from himself.
It is still the implementors duty to make sure things work properly.

3) True, the standard currently seems to put the burden on the end-user to save
the uncast (void *) value returned from malloc as well as the cast value, with
only the former used for free and realloc.  I have yet to see any program that
does so.

4) If the implementor of malloc wants to return odd pointers, knowing that
type-casting will round up (also UNUSUAL but legal), then he really should
implement free so that it will work even on all possible rounded-up values!
No sane compiler (actually, library) implementor should implement things that
don't work with common coding style.

5) The appropriate changes to the standard would be in the sections on free
and realloc.  In particular, 4.10.3.2 should be expanded to indicate not just
"a pointer earlier returned by the calloc, malloc, or realloc" but rather a
pointer that may have been cast using "(void *) (any-type *)" from the value
returned by calloc, malloc, or realloc.  Similar changes to 4.10.3.4.   Note
that this change is really NEEDED in the standard anyway to allow the end-user
to use the doubly-cast value for free rather than the original value.

6) By the way, it appears that if "void *" were bigger than other pointers, an
implementation would currently be free to hide any information (such as size,
buddy-pointers, etc.) that it wants in the value of malloc and expect to get it
back in the free call. The above fixes to the standard would prohibit this as
well (unless the object pointers also carried the extra "hidden" information).

7) By fixing the definitions of free and realloc, rather than restraining
pointer casting, we have left the maximal flexibility for the compiler and
library implementor.

8) By the way, pointer comparison between "OBJECT *" and "void *" requires that
the pointer to the object be (implicitly) converted to "void *".  Hence,
	void *x; mumble *y;
	y = (mumble *) (x = malloc(...));
	x == y
will probably yield false in this rounding implementation: a similar surprise
to the poor programmer (but legal).  Contrary to what someone stated earlier
in this thread, explicit type-casting is NOT required by the standard for
pointer comparison with "void *".  See the last paragraph of 3.3.9.  Hence,
I again recommend against the unusual rounding implementation.
-- 
==========================================================================
| Richard H. Gumpertz    rhg@cpsolv.UUCP -or- ...uunet!amgraf!cpsolv!rhg |
| Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749 |
==========================================================================