Xref: utzoo comp.std.c:1864 comp.lang.c:22996
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!xanth!ames!amdahl!altos!altos86!scott
From: scott@altos86.Altos.COM (Scott A. Rotondo)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: commom malloc/free practice breaks standard - author strikes back
Message-ID: <3683@altos86.Altos.COM>
Date: 18 Oct 89 21:39:27 GMT
References: <1989Oct16.111059.3840@anucsd.oz>
Reply-To: scott@altos86.UUCP (Scott A. Rotondo)
Followup-To: comp.std.c
Organization: Altos Computer Systems, San Jose, CA
Lines: 27

Brendan: I have trouble with both "most restrictive alignment" (only
	 used by the standard as a property of types, not of pointer
	 values) and "address unchanged" (see part (B) above).

Types have alignment restrictions.  The same restrictions apply to the
addresses represented by pointers to objects which have types.
Malloc() must return pointers whose addresses meet the most restrictive
of these alignment requirements.

Brendan: No doubt this problem was unintentional.  It could easily be
	 fixed by a sentence reading something like "The pointer
	 returned if the allocation succeeds is such that, if it is
	 cast to a pointer to any type of object and then that pointer
	 is cast to type void*, the original value is recovered."
Scott:   This is precisely the meaning of the section 4.10.3 alignment
	 rule.
Brendan: The intention, I'm sure.  The meaning is another matter.

Section 4.10.3 doesn't simply state that you must be able to cast or assign
the pointer and use it; it says that you must be able to use the pointer
because it is "suitably aligned."  Your hypothetical implementation only
meets the weaker of these two conditions.
-- 
===============================================================================
Scott A. Rotondo, Altos Computer Systems			 (408) 946-6700

{sun|pyramid|uunet}!altos86!scott				scott@Altos.COM