commom malloc/free practice breaks standard - author strikes back

[Conor P. Cahill]

In article <1989Oct16.111059.3840 at anucsd.oz>, bdm at anucsd.oz (Brendan McKay) writes:
> > That is the meaning of the "suitably aligned so that it may be
> > assigned to a pointer to any type of object and then used to access such an
> > object..." (Section 4.10.3).
>  
> That was probably the intention, but it certainly isn't what it says.
> My hypothetical implementation returns a value which can always be assigned
> to an OBJ* and used to access an OBJ.  Doesn't it?

Lets start again.  For any implementation there may exist alignment 
requirements that differ depending upon the type of data being dereferenced.
An example implementation will be where OBJ * must be aligned on a word
boundary, but void * can be on a byte boundary.

In this implementation malloc() MUST always return a pointer to the worst
case.  Another way of putting it is in the example above malloc must return
a OBJ * that is cast to a void *.  

So
		malloc gets a OBJ *, returns (void *) OBJ *
		which you then cast to an OBJ * which when you 
		call free you cast to a VOID * 

in a simpler wording

		OBJ * -> void * -> OBJ * -> void *

which IS REQUIRED by the standard.

> > An assignment of a void* pointer that is an invalid address for an OBJ*
> > will usually cause a core drop at the point of dereference and may cause
> > a core drop at the assignment.
>  
> The standard permits implementations where some pointer casting causes
> exceptions or results in values which cannot be deferenced.  It doesn't
> make such implementations compulsory.

And I didn't say it was compulsory.  That is the purpose of the *usually* that
I placed in the sentence.

> Is anyone out there brave enough to AGREE with me?

Brave has nothing to do with it.  You just don't understand the concept of
malloc() returning a suitably alligned pointer.


-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+