realloc question

[Blah]

suppose we have:

ptr = malloc(LARGE_AMOUNT);

and the call to malloc is succesful (non-NULL return).

is there any possibility of a later call to realloc like this:

tmp = realloc(ptr,SMALLER_AMOUNT);

to return NULL?

IOW, is it possible for realloc to fail when used to *reduce* the size of an
allocated memory block?

[Sheldon Simms]

On Fri, 07 Nov 2003 15:21:40 +0000, Blah wrote:

suppose we have:

ptr = malloc(LARGE_AMOUNT);

and the call to malloc is succesful (non-NULL return).

is there any possibility of a later call to realloc like this:

tmp = realloc(ptr,SMALLER_AMOUNT);

to return NULL?

IOW, is it possible for realloc to fail when used to *reduce* the size of an
allocated memory block?

Yes. At least the standard allows it to do so.
I can't imagine it would actually happen on most implementations, but
you must always check the return value of realloc to be sure.

[Dan Pop]

In <8M********************@news4.srv.hcvlny.cv.net> "Blah" <bl**@blah.com> writes:

suppose we have:

ptr = malloc(LARGE_AMOUNT);

and the call to malloc is succesful (non-NULL return).

is there any possibility of a later call to realloc like this:

tmp = realloc(ptr,SMALLER_AMOUNT);

to return NULL?

IOW, is it possible for realloc to fail when used to *reduce* the size of an
allocated memory block?

The comp.std.c party line is that *any* function that is allowed by the
standard to fail doesn't need an actual reason for failing. In
particular, even

tmp = realloc(ptr, LARGE_AMOUNT);

is allowed to fail, although this should be a no operation and there is
practically no difference if the function returns ptr or NULL.

But there are malloc implementations where there is a good reason for
failing in your scenario: the memory pool allocated for blocks of the
new size is full and the attempt to enlarge it by getting more memory
from the system has failed. By returning NULL, realloc lets you know
that your memory block still has its original size.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Blah]

"Dan Pop" <Da*****@cern.ch> wrote in message
news:bo**********@sunnews.cern.ch...

In <8M********************@news4.srv.hcvlny.cv.net> "Blah" <bl**@blah.com> writes:

suppose we have:

ptr = malloc(LARGE_AMOUNT);

and the call to malloc is succesful (non-NULL return).

is there any possibility of a later call to realloc like this:

tmp = realloc(ptr,SMALLER_AMOUNT);

to return NULL?

IOW, is it possible for realloc to fail when used to *reduce* the size of anallocated memory block?
The comp.std.c party line is that *any* function that is allowed by the
standard to fail doesn't need an actual reason for failing.

That certainly doesn't sound encouraging.

Does that mean something along the lines of:

int fprintf()
{
static int num = 0;
if ( num++ % 2 )
return real_fprintf();
else
return fail_fprintf();
}

would be conforming? Just fail on every other call because it feels like
it?

In particular, even

tmp = realloc(ptr, LARGE_AMOUNT);

is allowed to fail, although this should be a no operation and there is
practically no difference if the function returns ptr or NULL.
Just to make sure I understand you, if I call realloc() requesting that the
size of the memory block *does not change* it can fail?
But there are malloc implementations where there is a good reason for
failing in your scenario: the memory pool allocated for blocks of the
new size is full and the attempt to enlarge it by getting more memory
from the system has failed. By returning NULL, realloc lets you know
that your memory block still has its original size.

Not that having a memory block reduction fail is something difficult to work
around, but out of curiosity are there any known implementations that do
occasionally fail in this scenario?

[Glen Herrmannsfeldt]

"Blah" <bl**@blah.com> wrote in message
news:mm*********************@news4.srv.hcvlny.cv.n et...

(snip unrelated to realloc())

Just to make sure I understand you, if I call realloc() requesting that the size of the memory block *does not change* it can fail?

But there are malloc implementations where there is a good reason for
failing in your scenario: the memory pool allocated for blocks of the
new size is full and the attempt to enlarge it by getting more memory
from the system has failed. By returning NULL, realloc lets you know
that your memory block still has its original size.
Not that having a memory block reduction fail is something difficult to

work around, but out of curiosity are there any known implementations that do
occasionally fail in this scenario?

Some versions of realloc() always allocate new memory, copy old to new, and
free the old. In that case, it could fail even for a smaller region. That
is, even when reducing the size of the allocated memory.

-- glen

[Richard Bos]

"Blah" <bl**@blah.com> wrote:

"Dan Pop" <Da*****@cern.ch> wrote in message
news:bo**********@sunnews.cern.ch...

The comp.std.c party line is that *any* function that is allowed by the
standard to fail doesn't need an actual reason for failing.

That certainly doesn't sound encouraging.

Does that mean something along the lines of:

int fprintf()
{
static int num = 0;
if ( num++ % 2 )
return real_fprintf();
else
return fail_fprintf();
}

would be conforming? Just fail on every other call because it feels like
it?

Yes. It wouldn't _sell_, of course, but it would be conforming. The
Standard does not (and can not) address issues of Quality of
Implementation; that is left to market forces, i.e., us.

Richard

[Dave Thompson]

On Mon, 10 Nov 2003 09:49:21 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote:

"Blah" <bl**@blah.com> wrote:

"Dan Pop" <Da*****@cern.ch> wrote in message
news:bo**********@sunnews.cern.ch...

The comp.std.c party line is that *any* function that is allowed by the
standard to fail doesn't need an actual reason for failing.

That certainly doesn't sound encouraging.

Does that mean something along the lines of:

int fprintf()
{
static int num = 0;
if ( num++ % 2 )
return real_fprintf();
else
return fail_fprintf();
}

would be conforming? Just fail on every other call because it feels like
it?

Yes. It wouldn't _sell_, of course, but it would be conforming. The
Standard does not (and can not) address issues of Quality of
Implementation; that is left to market forces, i.e., us.

++nits: If it accepts and passes on the correct arguments/types, which
typically doesn't happen automatically for empty parens; and those
names, if actual functions, are either static (don't conflict with
user functions) or renamed to the implementation namespace;
and if signed-int overflow on that platform is well-defined or you use
unsigned instead. Although, if signed overflow wraps to negative and
%2 rounds down, as permitted in C89 and required in C99, it does not
fail as described = exactly every other call.

To extend the concept slightly, if( rand() %2U ), is nonconforming
because of 7.20.2.1p3: "The implementation shall behave as if no
library function calls the rand function." But
if ( __internalrand(&__separateseed) %2U ) is "OK".

- David.Thompson1 at worldnet.att.net