Xref: utzoo comp.std.c:965 comp.lang.c:17302
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: realloc
Keywords: realloc NULL
Message-ID: <1335@auspex.UUCP>
Date: 30 Mar 89 22:54:52 GMT
References: <10170@bloom-beacon.MIT.EDU> <2883@osiris.UUCP>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 33

>I'll say it's well-kept, neither the 4.2BSD nor SysV.2 manpages imply
>that calling realloc with first argument of 0 will do anything useful,
>let alone that it's *supposed* to.  The SunOS 4.0.0 manpage even says
>that "[realloc will fail if] an invalid argument was specified.

Yes.  However, the December 7, 1988 dpANS says:

	4.10.3.4 The "realloc" function

	Synopsis

		#include <stdlib.h>
		void *realloc(void *ptr, size_t size);

	Description

	  ... If "ptr" is a null pointer, the "realloc" function behaves
	like the "malloc" function for the specified size.

So, while the "well-kept secret" was, indeed, a secret in earlier
systems - since *no* promise about the behavior was listed in the
documentation - it's not likely to be a secret in ANSI C, unless that bit
gets deleted before the standard is issued.

So basically:

	1) if you know you'll only be running in ANSI C environments,
	   feel free to pass NULL as the first argument to "realloc"
	   (assuming that, in that case, you expect it to do a "malloc");

	2) if you *don't* know that, make sure all the assumptions you
	   made about your environment are backed up by the
	   documentation before you port to a new environment.