1. Reallocate() -- is this safe?
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?
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?
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
