realloc question

[James Brown]

Hi all,

I just wanted to make sure I understand realloc
void *realloc( void *memblock, size_t size );

1. when memblock is zero, realloc behaves like malloc
2. when memblock is non-zero, and size is the same as the
last time (i.e. memblock already big enough), then realloc is a "no-op"

I think #1 is true, but I am not sure about #2

thanks,
James

 

[aegis]

Hi all,

I just wanted to make sure I understand realloc
void *realloc( void *memblock, size_t size );

1. when memblock is zero, realloc behaves like malloc
2. when memblock is non-zero, and size is the same as the
last time (i.e. memblock already big enough), then realloc is a "no-op"

I think #1 is true, but I am not sure about #2

thanks,
James

For one, it is implementation defined. It will either
return a null pointer or a unique pointer value.
For two, it can either return the pointer value that
was passed to it or it can return a pointer value distinct
from the one passed to it.

 

[Keith Thompson]

I just wanted to make sure I understand realloc
void *realloc( void *memblock, size_t size );

1. when memblock is zero, realloc behaves like malloc
2. when memblock is non-zero, and size is the same as the
last time (i.e. memblock already big enough), then realloc is a "no-op"

I think #1 is true, but I am not sure about #2

The standard makes no guarantee of #2, and an implementation can move
the block of memory for any reasons, even frivolous ones.

More realistically, suppose the existing block of memory happens to be
in the middle of a large region that's otherwise unallocated. The
implementation might take advantage of the realloc() call to relocate
the block and merge the unallocated space, possibly making future
allocations easier.

 

[Eric Sosman]

Hi all,

I just wanted to make sure I understand realloc
void *realloc( void *memblock, size_t size );

1. when memblock is zero, realloc behaves like malloc

True.

2. when memblock is non-zero, and size is the same as the
last time (i.e. memblock already big enough), then realloc is a "no-op"

Not necessarily: realloc() may copy the existing data to
a new memory area and free the old one, even though this seems
silly. Silliness is not forbidden (and may even have its uses).

 

[Joe Wright]

Hi all,

I just wanted to make sure I understand realloc
void *realloc( void *memblock, size_t size );

1. when memblock is zero, realloc behaves like malloc
2. when memblock is non-zero, and size is the same as the
last time (i.e. memblock already big enough), then realloc is a "no-op"

I think #1 is true, but I am not sure about #2

thanks,
James

I don't know Jim, what does your book say?

 

[James Brown]

Hi all,

I just wanted to make sure I understand realloc
void *realloc( void *memblock, size_t size );

1. when memblock is zero, realloc behaves like malloc
2. when memblock is non-zero, and size is the same as the
last time (i.e. memblock already big enough), then realloc is a "no-op"

I think #1 is true, but I am not sure about #2

thanks,
James

ok thanks all,

James

 

[Jordan Abel]

Hi all,

I just wanted to make sure I understand realloc
void *realloc( void *memblock, size_t size );

1. when memblock is zero, realloc behaves like malloc
2. when memblock is non-zero, and size is the same as the
last time (i.e. memblock already big enough), then realloc is a "no-op"

I think #1 is true, but I am not sure about #2

#2 is not guaranteed. An implementation could legally do an
unconditional malloc/copy/free.

 

[Peter Nilsson]

Not necessarily: realloc() may copy the existing data to
a new memory area and free the old one, even though this seems
silly. Silliness is not forbidden (and may even have its uses).

I recall hearing that the authors of glibc have taken the standard
literally when it says "The realloc function deallocates the old object
pointed to by ptr and returns a pointer to a new object..." As such
realloc _always_ returns a different pointer to the original,
when realloc is successful. That includes when the new size is
the same or smaller than the original.

 

[Old Wolf]

Not necessarily: realloc() may copy the existing data to
a new memory area and free the old one, even though this seems
silly. Silliness is not forbidden (and may even have its uses).

The OP also shouldn't forget that any realloc() call may fail.

 

[=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=]

I recall hearing that the authors of glibc have taken the standard
literally when it says "The realloc function deallocates the old object
pointed to by ptr and returns a pointer to a new object..." As such
realloc _always_ returns a different pointer to the original,
when realloc is successful. That includes when the new size is
the same or smaller than the original.

Only in some very specific cases (when mmap() is used as backing store
and mremap() is not available)

DES

 

[Chuck F.]

Only in some very specific cases (when mmap() is used as backing
store and mremap() is not available)

So doing would be highly inefficient, since it forces copying of
the complete old content of the allocation. My malloc
implementation for DJGPP [1] goes to some lengths to avoid any such
copying, and will return the original pointer whenever it can do so.

[1] <http://cbfalconer.home.att.net/download/nmalloc.zip>

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=]

Only in some very specific cases (when mmap() is used as backing
store and mremap() is not available)

So doing would be highly inefficient, since it forces copying of the
complete old content of the allocation. My malloc implementation for
DJGPP [1] goes to some lengths to avoid any such copying, and will
return the original pointer whenever it can do so.

Sorry, I didn't realize it was "plug your software" week.

Like I said, glibc only does this when the object being realloc()d is
backed by mmap() and mremap() is not available. This is never the
case on Linux, which is pretty much the only platform glibc runs on.

DES

 

[Chuck F.]

So doing would be highly inefficient, since it forces copying
of the complete old content of the allocation. My malloc
implementation for DJGPP [1] goes to some lengths to avoid any
such copying, and will return the original pointer whenever it
can do so.

Sorry, I didn't realize it was "plug your software" week.

You have objections to pointing readers to an example of the
technique under discussion?

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=]

You have objections to pointing readers to an example of the technique
under discussion?

No, but I object to the use of strawman arguments, especially for
purposes of self-promotion.

DES

 

[Mark McIntyre]

No, but I object to the use of strawman arguments, especially for
purposes of self-promotion.

You can be pretty certain that this was not what Chuck was doing.
Perhaps you want to review those posts.
Mark McIntyre

 

[Chuck F.]

No, but I object to the use of strawman arguments, especially
for purposes of self-promotion.

I think you need to go back and read the thread. The point was the
possible inefficiency that can arise from forcing copying of
existing data. I pointed out that some reallocs go to lengths to
avoid it, and offered my package as an example. Since nmalloc is
tied to DJGPP and would require at least some effort to port
elsewhere, it is only an example. That package is under a free
license anyhow.

The effect can be quite dramatic when the object grows enough to
involve disk access for the copy. The following can be used as a test:

#include <stdio.h>
#include <stdlib.h>

/* Show the sequence of pointers from a series
of calls to realloc, with size doubling */
int main(void)
{
size_t sz;
char *p, *tmp;

sz = 1; p = NULL;
while (sz && (tmp = realloc(p, sz))) {
printf("sz = %8ld p = %p\n", (long)sz, (void *)tmp);
sz += sz; p = tmp;
}
return 0;
}

Results, *_ON MY SYSTEM_*

[1] c:\c\junk>gcc -c trealloc.c
[1] c:\c\junk>gcc trealloc.o -o trealloc.exe
[1] c:\c\junk>gcc trealloc.o malloc.o

*** Original malloc system ***
[1] c:\c\junk>timerun .\trealloc
Timer 3 on: 21:40:26
sz = 1 p = 90108
sz = 2 p = 90108
sz = 4 p = 90108
....
sz = 16777216 p = 10949a0
sz = 33554432 p = 20949b0
Timer 3 off: 21:40:27 Elapsed: 0:00:00.49

*** revised nmalloc system ***
[1] c:\c\junk>timerun .\a
Timer 3 on: 21:40:59
sz = 1 p = 90ce8
sz = 2 p = 90ce8
....
sz = 16777216 p = 95c78
sz = 33554432 p = 95c78
Timer 3 off: 21:40:59 Elapsed: 0:00:00.05

Incidentally the above also serves as an example of replacing the
system malloc on some systems. Note that this is not a portable
technique, and you can be seriously bitten.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=]

You can be pretty certain that this was not what Chuck was doing.
Perhaps you want to review those posts.

Sure. The conversation went somewhat like this:

<somebody> I've heard that glibc's realloc() does [something really
stupid and inefficient]

<me> Actually, it only does so under [conditions which never apply on
glibc's primary target platform]

<chuck> Hah! My realloc() is much better! It *never* does [what I
just pointed out that glibc doesn't do]

DES

 

[=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=]

I think you need to go back and read the thread. The point was the
possible inefficiency that can arise from forcing copying of
existing data. I pointed out that some reallocs go to lengths to
avoid it, and offered my package as an example.

And I objected to the manner in which you "offered your package as an
example". In the context of the discussion, it seemed that you were
promoting your implementation as a superior alternative to glibc's,
and the basis for that comparison is flawed.

Since nmalloc is tied to DJGPP and would require at least some
effort to port elsewhere [...]

Precisely; just as glibc is fairly strongly tied to Linux + gcc (it
also runs on Hurd, but with a different malloc() implementation). It
does however attempt to remain portable to platforms which do not have
the same facilities (mremap(2), in this case) as Linux.

DES

 

[Mark B]

I think you need to go back and read the thread. The point was the
possible inefficiency that can arise from forcing copying of
existing data.

The thread had nothing to do with efficiency... that was a point
that you had made to give yourself an excuse to pimp your code
on clc again... which you do frequently.

I pointed out that some reallocs go to lengths to
avoid it, and offered my package as an example.

An example wasn't necessary this time, but clc regulars
understand that you can't help yourself.

Since nmalloc is tied to DJGPP and would require at least some effort to
port elsewhere, it is only an example. That package is under a free
license anyhow.

That's a good pimp... never miss a chance to advertise your girls ;-)
You really can't help yourself, can you?

<snip code provided to promote code posted earlier>

Yes, CBF is a code pimp. He's proud of his work and enjoys
sharing it with others. That being said, many of his advertisements
are a direct response to legitimate questions, and he can often help
these posters whether it be through the actual use of his code or
their being able to reference it as an example. If he can help
1 out of 10 of these posters, then more power to him.

Pimp away CBF.

 

[Mark McIntyre]

that you had made to give yourself an excuse to pimp your code
on clc again... which you do frequently.

Bullshit. Like many of us, Chuck posts links to examples of code that
he's written. If you don't like that, then move on, the5re's nothing
for you here.

Mark McIntyre