Hi. I have some questions about C's memory allocation functions.
Let's assume buf is a pointer to storage allocated with malloc, and
n is a positive integer. What do these funtion calls do and return?

malloc(0)
realloc(buf, 0)
realloc(0, n)
realloc(0, 0)
free(0)

And some more questions:
If I call realloc(buf, n) and it fails, is the old buffer lost?
Does realloc(buf, n) always succeed if n is less than the old size
of the buffer?
--

Implementation-defined.  Either a null pointer or a unique pointer.

Assuming buf points to a previously-allocated and never-freed buffer,
The buffer is freed.  Otherwise, if buf is not a null pointer, the
behavior is undefined.

I believe it must return a null pointer, but I'm not certain.

Behaves as malloc(n)

Behaves as malloc(0)

No action occurs.

No.

There's no guarantee.  However, if it does fail, the old buffer
remains.

Regards,

                               -=Dave
--
Change is inevitable, progress is not.
--

Implementation defined.  May return NULL or a value.  If a value, the
value may not be dereferenced.
The area pointed to by buff is deallocated (freed).  Return value same
as malloc(0) above.
Identical to malloc(n).
Identical to malloc(0) above.
Not guaranteed.  I wonder if there are any implementations where it
could fail.

<<Remove the del for email>>
--

realloc(NULL, n) is equivalent to malloc(n).  free(NULL) is a
run-time error, or at least undefined behaviour.  The others are
implementation defined. (0 is equivalent to NULL in C when used as
a pointer)

If you overwrite the contents of the pointer 'buf', yes, otherwise
no.  So you never write "buf = realloc(buf, whatever);" but use:

  if (temp = realloc(buf, whatever)) buf = temp;
  else {
     /* miserable failure, buf unharmed */
  }

Not necessarily.

My proposed version for the DJGPP system, which is quite portable,
can be seen at:

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

All the GCC dependant macros can be redefined to nothing via
NDEBUG.  Unfortunately the calls remain non-standard for non GCC
compilers, but can be simply commented out.  Until C99 varargs
macros are available that will remain.

--

   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!
--

Any complete textbook on C should tell you this, but...

Either null, or a (useless) pointer to zero bytes of memory.

Same thing as malloc(n).

Same thing as malloc(0)...

Nothing.

No. The buffer still exists at the old address, but realloc() returns a
null pointer. That is why this:

  ptr=realloc(ptr, newsize);

is a bad idea; if realloc() fails, your old address is lost, and you've
leaked that memory.

That's a quality of implementation issue, so the Standard doesn't
(AFAICT) address it, but I'd be disappointed in an implementation that
didn't.

Richard
--

Implementation-defined.

Implementation-defined.

Equivalent to malloc(n).

Implementation-defined.

In all of the above, the result is still required to be either a null
pointer or pointer to allocated memory, i.e. the implementation isn't
at liberty to return garbage or kill your program, just like that

Nothing happens. No value returned.

No.  That's why you should never

        buf = realloc(buf, n);

but rather something like this:

        {
           void * temp = realloc(buf,n);

           if (temp)
              buf = temp;
           else {
              /* error, optionally tell user about it */
           }
        }

Usually it will.  But don't bet your home on that --- it's not
strictly guaranteed, so there may well be some extra-peculiar platform
where it can fail.  Either check it didn't fail, or avoid calling
realloc() for downsizing.
--

Even if all the snow were burnt, ashes would remain.
--

| Hi. I have some questions about C's memory allocation functions.
| Let's assume buf is a pointer to storage allocated with malloc, and
| n is a positive integer. What do these funtion calls do and return?
|
| malloc(0)

The behavior is implementation-defined: the value returned is either a null
pointer or a unique pointer.

| realloc(buf, 0)

If buf is a non-null pointer whose value is returned by a previous call to
calloc, malloc or realloc and has not been deallocated by a subsequent call
to free or realloc: the object pointed to by buf is deallocated. If buf is a
null-pointer the behavior is equivalent to malloc(0). Either a null pointer
or a unique pointer that can be successfully passed to free is returned.

| realloc(0, n)

Equivalent to malloc(n).

| realloc(0, 0)

Equivalent to malloc(0)

| free(0)

No action.

|
| And some more questions:
| If I call realloc(buf, n) and it fails, is the old buffer lost?

No. Upon success: the object remains unchanged up to the lesser of the new
and old sizes. Upon failure: the object remains unchanged.

| Does realloc(buf, n) always succeed if n is less than the old size
| of the buffer?

No.
--

`malloc(0)' is allowed to return either a null pointer, or a non-null
pointer that does not point to an object.  (There has been debate in
other newsgroups over whether multiple calls to `malloc(0)' must
return different non-null pointers, but since the implementation is
always allowed to return null instead, I don't think it makes any
practical difference.)

Equivalent to `free(buf)'.

Equivalent to `malloc(n)'.

Equivalent to `malloc(0)'.  See above.

Does nothing.

No, but a common mistake is to write code that loses the only pointer
to the buffer, like this.

    buf = realloc(buf, n);
    if (!buf) {
        ... deal with out of memory condition, but we no longer have
            a pointer to the buffer

If "dealing" with the lack of memory just means exit()ing, this is no
problem, but if you need to clear up, you have to write code like
this.

    newbuf = realloc(buf, n);
    if (newbuf) buf = newbuf;
    else {
        ... deal with out of memory condition: buf is still valid

No.  There are plausible memory allocation strategies which can't make
this guarantee, so it is not required by the standard.

Tim.
--
Tim Goodwin   | "But fixing the entire UNIX system is not
Leicester, UK | on my TODO list. (Yet.)" -- Dan Bernstein
--

Nice quiz.  Let's see how I do.

Returns something implementation dependent, sometimes null, but it
won't crash the program.

Same as free(buf)

Same as malloc(n).  Common idiom.

Same as malloc(0)

Does nothing.  Common idiom.

The contents of memory are unchanged.  But if you do

        buf = realloc(buf,n)

and you haven't saved a copy of the buf pointer somewhere, you lose
the pointer.  I do something like

        tmp = realloc(buf,n);
        if (tmp != null) {
                buf = tmp;
        }

Stumped.  My intuition would say yes, but I wonder if the standard
guarantees it.  I've never needed to realloc to a smaller value.

--

--

these are quality of implementation issues.  NULL would be understandable,
but most probably return a pointer that you can/dare/should not dereference.
in the later case memory is probably allocated (hence removed from the free
list/pool/space/&c), though as with other allocation requests you shouldn't
expect any such slop to actually be available for use.

as if malloc were called, i.e., malloc(n) and malloc(0) respectively.

nothing.

no, as long as you don't hose buf by doing ``buf=realloc(buf,n)''.

it's likely to succeed, but there is no guarantee.  be defensive, expect to
handle failures.

--
bringing you boring signatures for 17 years
--

[snip malloc(0), realloc(0), etc]

These sound like homework questions.  The answers are available to a
cursory google search, and even a quick glance at either K&RII or
the standard will tell you the answers.  You should do your own
homework, or else explain why this is not a pathetic plea for someone
else to do your homework for you.

-andy
--

Return is implementation dependent, but you should never
dereference it.  i.e. treat it like a NULL pointer, even though it's
value may be different from NULL.

Assuming buf was allocated by malloc/calloc/realloc, it is
deallocated.  The returned value is (like malloc (0)) implementation
dependent, and should never be dereferenced.

Like malloc(n).

Special case of the previous value: like malloc(0)

No effect.

No.  That is actually the purpose of realloc.

Not formally guaranteed.   In practice, it will often succeed, but if
you genuinely care about portability and maintenance you need
to allow for the possibility it won't.
--

So to summarize:

Either a null pointer or a unique pointer
- or -
Either a null pointer or some other pointer

Same as free(buf), returning null
- or -
Same as free(buf), returning some pointer

Same as malloc(n)
(Everybody agrees about this one!)

Same as malloc(0)
(Everybody agrees about this one, too)

Does nothing
- or -
Crashes your program

/peter
--

Good grief, I would expect you to know that free(NULL) is guaranteed to
be a no-op!

Tony.
--

BAILEY: VARIABLE BECOMING SOUTHEASTERLY 3 OR 4, INCREASING 5 OR 6 IN WEST
LATER. SHOWERS. GOOD.
--

No, it's the same as malloc(0), i.e. implementation-defined.

Tony.
--

DOVER WIGHT: WEST OR NORTHWEST VEERING NORTHEAST 3 OR 4, OCCASIONALLY 5 LATER.
THUNDERY SHOWERS DYING OUT. MODERATE OR GOOD.
--