🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c
Article #721

Re: commom malloc/free practice breaks standard - author strikes back

#721
From: Conor P. Cahill
Date: Tue, 17 Oct 1989 00:57
51 lines
2583 bytes
In article <1989Oct16.111059.3840@anucsd.oz>, bdm@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     |
+-----------------------------------------------------------------------+
Technical Details
Message-ID: <1284@virtech.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!virtech!cpcahil
References: <1989Oct16.111059.3840@anucsd.oz>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!virtech!cpcahil
From: cpcahil@virtech.UUCP (Conor P. Cahill)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: commom malloc/free practice breaks standard - author strikes back
Message-ID: <1284@virtech.UUCP>
Date: 17 Oct 89 00:57:48 GMT
References: <1989Oct16.111059.3840@anucsd.oz>
Organization: Virtual Technologies Inc
Lines: 51