Dan Karron@UCBVAX.BERKELEY.EDU (02/15/91)
I am curious about the realloc function. Usually I build a linked list when you don't know how many elements of a table I need at the start of some operation. With realloc, you can grow the end of your table allocation block as you need the space, plus have the advantage of keeping all of the elements of your list in the form of an array. I think that this is really neat! This means that many applications that formerly were implimented as linked lists (single, or double,forward/backward linkages) can now be done as growable/shrinkable arrays. How does this work ? The documentation says that realloc'ed pointers can be moved by realloc, but I have tested the pointers on entry and exit and they never seem to move. Does realloc create holes in your heap ? Which way is the new preferred practice: linked lists or realloc'd arrays ? Cheers! Dan(who wants to unlink and array) +-----------------------------------------------------------------------------+ | karron@nyu.edu (E-mail alias that will always find me) | | Fax: 212 263 7190 * Dan Karron, Research Associate | | . . . . . . . . . . . . . . * New York University Medical Center | | 560 First Avenue \*\ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> <your-number-here> | | (212) 263 5210 \***\_________________________________________ | | Main machine: karron.med.nyu.edu (128.122.135.3) IRIS 85GT | +-----------------------------------------------------------------------------+ NOTE PHONE NUMBER CHANGE: The Med Ctr has changed from 340 to 263 exchange.
sweetmr@SCT60A.SUNYCT.EDU (michael sweet) (02/15/91)
Actually, the way realloc() does its realloc'ing is implementation dependent (oh, boy!) *Most* realloc()'s try to expand the existing block first, and only malloc() a new block if necessary. This *will* create holes if you do a lot of small realloc()'s; memory is generally grabbed in chunks which are either a minimum size, or the size of the requested amount (whichever is larger.) As the amount you realloc() grows larger, you will create (concievably) large wholes in the heap (if memory is not contiguous), and causing much swap-space thrashing! :) (voice of experience...) The easy fix for this is to allocate memory in multiples of a minimum size, reducing the number of realloc()'s you have to do; you'll also need a variable (or structure field) which keeps track of the last amount allocated... Or of course you can use the K&R malloc()/free() functions and add your own realloc() which rounds request sizes to some minimum size multiple... -Mike Sweet ------------------------------------------------------------------------------ "The only TASC (315) 724-1100 (voice) truth is that 555 French Road (315) 724-2031 (fax) there are no New Hartford, NY 13413 Internet: sweetmr@sct60a.sunyct.edu truths, only beliefs." Delphi: DODGECOLT ------------------------------------------------------------------------------
slamont@network.ucsd.edu (Steve Lamont) (02/16/91)
In article <9102150952.AA24219@karron.med.nyu.edu> karron@cmcl2.nyu.edu writes: > >I am curious about the realloc function. Me too, but for a different reason than Dan. Why does SGI's realloc() barf on a null pointer. F'rinstance #include <stdio.h> #if defined( mips ) #include <malloc.h> #else if defined( __STDC__ ) #include <stdlib.h> #else char *realloc(); #endif main() { char *foo = ( char *) NULL; foo = ( char *) realloc( foo, 100 ); printf( "I allocated foo at %08lx\n", foo ); exit( 0 ); } provides me with Bus error (core dumped) in small, unfriendly letters on an SGI. On all other platforms it gives me a valid pointer. Bug, feature, misfeature, or hallucination? spl (the p stands for plethora of pointers) -- Steve Lamont, SciViGuy -- (408) 646-2572 -- a guest at network.ucsd.edu -- NPS Confuser Center / Code 51 / Naval Postgraduate School / Monterey, CA 93943 "Unix is not a "A-ha" experience, it is more of a "holy-shit" experience." - Colin McFadyen in alt.folklore.computers
shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) (02/16/91)
In article <4786@network.ucsd.edu> slamont@network.ucsd.edu (Steve Lamont) writes: >In article <9102150952.AA24219@karron.med.nyu.edu> karron@cmcl2.nyu.edu writes: >> >>I am curious about the realloc() function. > >Me too, but for a different reason than Dan. Why does SGI's realloc() barf on >a null pointer.... C'mon, you're not serious, are you? Realloc() expects its first arg to be a pointer to some block of storage. For example, the man page (IRIX 3.2.1) says, "The contents [of the new storage allocated] will be unchanged up to the lesser of the new and old sizes". If the first arg of realloc() doesn't point to anything, clearly the result is undefined. And NULL, of course, cannot point to anything. (Other peoples' man pages explicitly state that realloc()'s first arg must be a pointer previously returned by malloc, calloc or realloc.) Now let me guess why you're trying to do this. You have a routine in which you're trying to allocate new storage each time you come in. The first time you want to malloc(), and subsequent times you want to realloc(), perhaps to grow an array from size zero up to some ultimate size that is unknown until the program runs. So you figure that doing a realloc() with NULL as a first arg is as good a way as doing malloc() as any other. Sorry, no can do! In this situation I usually something like: .... int nbyte; /* additional bytes to be allocated now */ int nptr = 0; /* number of bytes now pointed to by ptr */ char *ptr = NULL; .... if( ptr == NULL ) ptr = malloc( (unsigned)nbyte ); else { ptr = realloc( ptr, (unsigned)(nptr + nbyte) ); } assert( ptr != NULL ); /* make sure alloc worked */ nptr += nbyte; .... ************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************** Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027 (212)854-1418 shenkin@cunixf.cc.columbia.edu(Internet) shenkin@cunixf(Bitnet) ***"In scenic New York... where the third world is only a subway ride away."***
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (02/19/91)
> Why does SGI's realloc() barf on > a null pointer.... There is a brand of solar workstation with a free() that does not care what it's arg is. You can free() automatic variables, because their version first tries to validate the pointer, and ignores what looks wrong. The code written by that engineering organization is--let's be polite--care free about malloc/free/realloc args. Some of us consider that practice less than fastidious, and while not strictly wrong, similar to using int's as pointers. For years we have been painfully aware of such solar code, including kernel code. Being careful to always pass good things to free & relloc makes correct code bigger, but also makes incorrect code fail sooner. The hard malloc bugs are the ones whose corruption causes disaster 10e10 cycles later. Vernon Schryver, vjs@sgi.com