Xref: utzoo comp.std.c:995 comp.lang.c:17361
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: realloc
Keywords: if NULL == 0
Message-ID: <16678@mimsy.UUCP>
Date: 3 Apr 89 00:17:38 GMT
References: <10170@bloom-beacon.MIT.EDU> <10032@ihlpb.ATT.COM> <1196@cmtl01.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 39

[flaming about realloc((char *)NULL) deleted]

In article <1196@cmtl01.UUCP> oisin@cmtl01.UUCP (Oisin) writes:
>Pardon my ignorance, but if I'm wrong you can flame me too...
>Does the draft not specify that whatever implementation of NULL is used, 
>the compiler must guarantee that a ptr containing that implementation's
>version of NULL must test as false?

Yes.  In standard-ese, a null pointer of any type must compare equal
to the integer constant zero and to the nil-pointer-to-void ((void *)0).
This has nothing to do with the flaming about

	realloc((char *)NULL, sz),  where sz > 0

nor that about

	malloc((size_t)0)
and	realloc(ptr, (size_t)0)

(The `correct' set of definitions---which is not the same as the pANS
set, but is fairly close; I can deal with the pANS version---appears
to me to be:

	malloc(sz) should return a unique pointer to at least sz bytes,
	or the value (void *)NULL if space is not available

	free((char *)NULL) should be a no-op, not an error

	realloc(ptr, sz) should `act like' free(ptr)+malloc(sz)+copy(old
	data, new location).  In particular, realloc(NULL) should act
	like malloc, and realloc(?, 0) should return a unique pointer to
	at least zero bytes.

This could be done in an ANSI-conformant environment with a small set
of wrapper functions.  Note that, with these definitions, malloc()
becomes unnecessary; it need not appear as a wrapper function.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris