Xref: utzoo comp.std.c:947 comp.lang.c:17273
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!labrea!rutgers!bellcore!faline!thumper!ulysses!andante!alice!ark
From: ark@alice.UUCP (Andrew Koenig)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: realloc
Message-ID: <9118@alice.UUCP>
Date: 29 Mar 89 20:27:29 GMT
References: <10170@bloom-beacon.MIT.EDU> <10032@ihlpb.ATT.COM>
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 35

In article <10032@ihlpb.ATT.COM>, gregg@ihlpb.ATT.COM (Wonderly) writes:

> I read the man page for realloc and it said nothing about this.  Is it
> not possible for you to type
> 
> 	if (ptr == NULL)
> 		ptr = malloc (nbytes);
> 	else
> 		ptr = realloc (ptr, nbytes);
> 
> or are you one of those people that assumes (*((char *)NULL) == 0) too?
> This damn lazy programming and sorry excuses for not being defensive has
> got to stop.

Hm.  Here's what my draft ANSI C spec has to say about realloc:

	void *realloc(void *ptr, size_t size);

The realloc function changes the size of the object pointed to by
`ptr' to the size specified by `size.'  The contents of the object
shall be unchanged up to the lesser of the new and old sizes.  If
the new size is larger, the value of the newly allocated portion
of the object is indeterminate.  If `ptr' is a null pointer, the
realloc function behaves like the malloc function for the
specified size...

---------

Of course, not all C implementations behave this way.  This
leaves C programmers in a bind: rely on this behavior or not?  If
not, how does one determine which behavior can be trusted?  If
so, what does one do when one's code breaks on various machines?
-- 
				--Andrew Koenig
				  ark@europa.att.com