Xref: utzoo comp.std.c:1841 comp.lang.c:22939
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ark1!nems!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: commom malloc/free practice breaks standard - author strikes back
Message-ID: <20203@mimsy.umd.edu>
Date: 17 Oct 89 03:14:33 GMT
References: <1989Oct16.111059.3840@anucsd.oz> <1284@virtech.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 23

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

In article <1284@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
>Brave has nothing to do with it.  You just don't understand the concept of
>malloc() returning a suitably alligned pointer.

I am sure the fellow *does* understand the concept.  He is not saying
that this is (or is not) how things work.  He is simply saying that, in
his reading, the proposed standard does not make sufficient constraints
on the implementation to force the implementation to work.  In his
opinion, it would be possible for an implementation to conform to the
letter of the standard, yet have code like

	p = (struct foo *)malloc(sizeof(struct foo));
	if (p == NULL) ... handle error ...
	... use *p ...
	free((void *)p);

break.
-- 
`They were supposed to be green.'
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris