From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "Douglas A. Gwyn" Message-ID: <3D8642ED.6BE57EE6@null.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: Subject: Re: [9fans] manual suggestions and upas/fs bug Date: Tue, 17 Sep 2002 08:47:45 +0000 Topicbox-Message-UUID: ecfe83f4-eaca-11e9-9e20-41e7f4b1d025 David Swasey wrote: > The malloc(2) page says: > The call realloc(0, size) means the same as `malloc(size)'. > Further, the call realloc(ptr, 0) means the same as > `free(ptr)'. > I suggest you clarify the meaning of realloc(0,0). If the intention is to be standard-conforming, then realloc(0,x) is the same as malloc(x) for all x. malloc(0) is required to return either a null pointer or a valid heap pointer (which a strictly conforming program is not allowed to dereference). realloc(p,0) cannot be identical to free(p) since the former returns a value and the latter does not. Presumably it acts as free(p) then does not succeed in allocating a 0-sized new object, thus returns a null pointer. free(0) is required to be a no-op. > diff /n/dump/2002/0916/sys/src/cmd/upas/fs/mbox.c mbox.c > 1358c1358,1362 > < p = realloc(p, n); > --- > > if(n==0){ > > free(p); > > p = malloc(n); > > } else > > p = realloc(p, n); p = realloc(p,n) is almost always a mistake. If the allocation fails, the previous pointer value in p gets replaced by a null pointer value, so you lose the handle to the data that did not get extended (or, rarely, shrunk).