1. Reallocate() -- is this safe?
- Posted by Andy Serpa <ac at onehorseshy.com> Oct 13, 2002
- 358 views
Hello, function reallocate(atom old_addr, atom size) atom new_addr new_addr = allocate(size) mem_copy(new_addr,old_addr,size) -- safe? free(old_addr) return new_addr end function If the new block is bigger we will be copying stuff beyond what was in the original block -- might we run up against the "edge" of available memory? Is that possible, and what will happen? If it is not safe, is there a way to tell how big the original block was without keeping explicit track at allocate()-time? I don't suppose there is a way to call realloc() directly with some undocumented machine_func()?
2. Re: Reallocate() -- is this safe?
- Posted by Robert Craig <rds at RapidEuphoria.com> Oct 13, 2002
- 367 views
Andy Serpa writes: > If the new block is bigger we will be copying stuff beyond > what was in the original block -- might we run up against > the "edge" of available memory? Is that possible, > and what will happen? Yes, it's possible, and you'll get a machine-level exception in that case. > If it is not safe, is there a way to tell how big the > original block was without keeping explicit track > at allocate()-time? Every C compiler uses a different implementation of malloc(). Most, but not all, malloc's store the length of the block, or something similar, in the 4 bytes preceeding the address returned by malloc(). I think Watcom's malloc (ex, exw) stores the length of the block plus 5, so Euphoria's allocate() will currently do the same on DOS and Windows, but I don't guarantee that will always be the case. For portability, you'd be well advised to allocate an extra 4 bytes, and store the length yourself, or keep track of the length in some variable. > I don't suppose there is a way to call realloc() > directly with some undocumented machine_func()? No. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
3. Re: Reallocate() -- is this safe?
- Posted by jbrown105 at speedymail.org Oct 14, 2002
- 409 views
I dont understand, why not just wrap the C version of realloc? (Only DOS programming will prevent you from doing this.) And if you cant, try out this untested function: global function reallocate(atom oldptr, integer oldsize, integer newsize) atom newptr if oldsize = newsize then return oldptr end if newptr = allocate(size) if newptr = NULL then return oldptr end if if oldsize > newsize then memcopy(newptr, oldptr, newsize) else memcopy(newptr, oldptr, oldsize) end if free(oldptr) return newptr end function jbrown On 0, Robert Craig <rds at RapidEuphoria.com> wrote: > > Andy Serpa writes: > > If the new block is bigger we will be copying stuff beyond > > what was in the original block -- might we run up against > > the "edge" of available memory? Is that possible, > > and what will happen? > > Yes, it's possible, and you'll get a machine-level exception > in that case. > > > If it is not safe, is there a way to tell how big the > > original block was without keeping explicit track > > at allocate()-time? > > Every C compiler uses a different implementation of malloc(). > Most, but not all, malloc's store the length of the block, > or something similar, in the 4 bytes preceeding the > address returned by malloc(). I think Watcom's malloc (ex, exw) > stores the length of the block plus 5, so Euphoria's allocate() > will currently do the same on DOS and Windows, > but I don't guarantee that will always be the case. > > For portability, you'd be well advised to allocate an extra > 4 bytes, and store the length yourself, or keep track of the > length in some variable. > > > I don't suppose there is a way to call realloc() > > directly with some undocumented machine_func()? > > No. > > Regards, > Rob Craig > Rapid Deployment Software > http://www.RapidEuphoria.com > Linux User:190064 Linux Machine:84163