achowe@tiger.waterloo.edu (anthony howe) (12/14/89)
I'm making use of realloc() from the Dale's dlibs. However I wonder
how close this function is to a standard unix site. In Dale's version
if <addr> is NULL then a malloc is done. If <size> is zero then a
free is done. Else resized and possibly moved block of memory.
NULL may be returned is the block can not be resized.
Now the man page for realloc() here at U(W) does not say anything
except that the block is resized and possibly moved and that NULL
may be returned if the resize fails.
What is the standard action realloc should take on when passed a
NULL address or a size of zero?
In particular the issue of size zero. Does a unix realloc() free
or size down to zero?
- ant
achowe@tiger.waterloo.edu | "It is hard to make the world go away
_ -|-|_ _ | when it has decided to notice you."
(_\ |\| | | | (_) |\| \/ | - Spock's World
___/ | disclaimer...steve@thelake.UUCP (Steve Yelvington) (12/15/89)
In article <19281@watdragon.waterloo.edu>, achowe@tiger.waterloo.edu (anthony howe) writes ... > >I'm making use of realloc() from the Dale's dlibs. However I wonder >how close this function is to a standard unix site. In Dale's version >if <addr> is NULL then a malloc is done. If <size> is zero then a >free is done. Else resized and possibly moved block of memory. >NULL may be returned is the block can not be resized. > >Now the man page for realloc() here at U(W) does not say anything >except that the block is resized and possibly moved and that NULL >may be returned if the resize fails. > Dale's version is in accord with the interpretation of the draft ANSI standard described in "C: A Reference Manual," Harbison and Steele, Tartan Laboratories (Prentice-Hall), second edition. char *realloc(ptr,size) char *ptr; unsigned size; "If the first argument to realloc is a null pointer then the function behaves like malloc .... if ptr is not null and size is zero, realloc returns a null pointer and the old region is deallocated." I recommend the book. It's the "other C bible," along with K&R. -- Steve Yelvington at the (frozen enough to skate!) lake in Minnesota UUCP: ... pwcs.StPaul.GOV!stag!thelake!steve
dal@syntel.mn.org (Dale Schumacher) (12/16/89)
[achowe@tiger.waterloo.edu (anthony howe) writes...] > > I'm making use of realloc() from the Dale's dlibs. However I wonder > how close this function is to a standard unix site. In Dale's version > if <addr> is NULL then a malloc is done. If <size> is zero then a > free is done. Else resized and possibly moved block of memory. > NULL may be returned is the block can not be resized. > > Now the man page for realloc() here at U(W) does not say anything > except that the block is resized and possibly moved and that NULL > may be returned if the resize fails. > > What is the standard action realloc should take on when passed a > NULL address or a size of zero? > > In particular the issue of size zero. Does a unix realloc() free > or size down to zero? Much of this behaviour, though convenient, is new with ANSI C. I thought it would be helpful to include it, since it's upwardly compatible with old code. Thus speaks X3.159... Description 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. Otherwise, if 'ptr' does not match a pointer earlier returned by the 'calloc', 'malloc' or 'realloc' function, or if the space have been deallocated by a call to the 'free' or 'realloc' function, the behaviour is undefined. If the space cannot be allocated, the object pointed to by 'ptr' is unchanged. If 'size' is zero and 'ptr' is not a null pointer, the object it points to is freed. Returns The 'realloc' function returns either a null pointer or a pointer to the possibly moved allocated space. Now having said that, I want to report a bug in dLibs 'realloc' recently located and fixed by Anthony... > Description: > realloc() fails to shrink properly for real small chunks > (smaller than the size of a header + pointer field). The guts of the fix are a few lines in the source file "realloc.c" at the beginning of the realloc() function itself. > if(addr == NULL) > return(lalloc((long) size)); > if(size == 0) > { > free(addr); > return(addr); > } > p = addr - 1; > n = p[0] & 0x00FFFFFFL; /* get actual block size */ >/* buggy line > m = (((long) size) + 5L) & ~1L; /* calculate new block size */ > >/* fix here */ > if( size <= 4 ) > m = 8L; > else > m = (((long) size) + 5L) & ~1L; /* calculate new block size */ Thanks to Anthony Howe (and Michal Jaegermann who relay this report and has reported several previous bugs) for finding and fixing this. One final note about dLibs... version 2.0 is in development, and has been for some time. It will still be something like 6 months before it is completed, but it's a complete rewrite with major contributions from a great number of talented "net gods". It will be fully ANSI compliant and quite a bit better than dLibs 1.2, or any other C library I've seen. In fact, it's very possible that NO dLibs 1.2 code will survive to be included in the final 2.0 :-) \\ / Dale Schumacher 399 Beacon Ave. \\ / (alias: Dalnefre') St. Paul, MN 55104-3527 >< ..!nic.mr.net!bungia.mn.org!syntel!dal United States of America / \\ "The power of accurate observation is commonly called cynicism / \\ by those who have not got it." -George Bernard Shaw