What happens if I re-alloc and the new size is 0. Is this equivalent with a free?
Asked Answered
D

4

8

Given the following code:

int *a = NULL;
a = calloc(1, sizeof(*a));
printf("%d\n", a);
a = realloc(a, 0);

printf("%d\n", a);
return (0);

It returns:

4078904
0

Is this realloc equivalent to a free ?

NOTE: I am using MinGW under WindowsXP.

Diminished answered 30/3, 2010 at 15:44 Comment(0)
M
5

Not necessarily.

It often does as with the link that munissor posted, but the Mac OS 10.5 man page says:

If size is zero and ptr is not NULL, a new, minimum sized object is allocated and the original object is freed.

What is a "minimum sized object"? Well, any allocator stores some information about the allocations, and that takes space which is often allotted in addition to the space reserved for the user. Presumably a "minimum sized object" is just one of these headers plus zero bytes of space reserved for the user.

I would guess that this provision is present to support implementations that existed at the time of standardization, and that those implementations are useful for debugging allocation behavior.


To address Jonathan's comments

Consider the difference between

for (int i=0; i<VERY_BIG_NUMBER; ++i){
  char *p = malloc(sizeof(char[10]));
  free(p);
}

and

for (int i=0; i<VERY_BIG_NUMBER; ++i){
  char *p = malloc(sizeof(char[10]));
  realloc(p,0);
}

With a sane implementation of malloc and free the first clip does not consume memory without bound. But if the realloc implementation returns those "minimum sized objects" it might.

Certainly this example is contrived and it relies on understanding what is meant by "minimum sized object", but I think that text allows it.

In short, if you mean free you should say free.

Macmillan answered 30/3, 2010 at 15:48 Comment(4)
I think that those implementation are NOT following the C specification. Have a look also at opengroup.org/onlinepubs/009695399/functions/realloc.htmlMenu
@munissor: This behavior is conforming. From the POSIX spec: "If size is 0, either a null pointer or a unique pointer that can be successfully passed to free() shall be returned" (emphasis mine). It is also conforming to the language in the C standard.Praedial
@munissor: I don't have my K&R handy so I can't compare to the '89 standard, but the Mac OS uses the BSD implementation which has been around for a long time. Certainly the link that James McNellis posted suggests that this behavior is allowed under the '99 standard. In any case, the results are nearly the same. (I suspect the "minimum sized object" is there to support some malloc debuggers.)Macmillan
@james, @dmkee Good to know! Never trust what you can find on Google ;)Menu
P
8

It may or may not be equivalent to calling free on the pointer; the result is implementation-defined.

From the C99 standard (§7.20.3/1):

If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object.

That applies to all of the memory management functions, including realloc.

Praedial answered 30/3, 2010 at 15:55 Comment(2)
It is equivalent to calling free in that the original memory is no longer available for use. See also my answer - which quotes the information from §7.20.3.4 (realloc) as well as the section you quote. The material in §7.20.3.4 overrides the general comment - or, rather, specifies that realloc() frees - deallocates - the original memory and then does the equivalent of a malloc() for the new size, which is equivalent to malloc(0) in this case, and then gets your quoted behaviour. The key distinction is that realloc() unconditionally releases the old memory first.Porky
@Jonathan: If the behavior is "as if the size were some nonzero value," then failing to free the resulting pointer would result in a memory leak. In that case, it is not strictly equivalent to calling free on the pointer.Praedial
M
5

Not necessarily.

It often does as with the link that munissor posted, but the Mac OS 10.5 man page says:

If size is zero and ptr is not NULL, a new, minimum sized object is allocated and the original object is freed.

What is a "minimum sized object"? Well, any allocator stores some information about the allocations, and that takes space which is often allotted in addition to the space reserved for the user. Presumably a "minimum sized object" is just one of these headers plus zero bytes of space reserved for the user.

I would guess that this provision is present to support implementations that existed at the time of standardization, and that those implementations are useful for debugging allocation behavior.


To address Jonathan's comments

Consider the difference between

for (int i=0; i<VERY_BIG_NUMBER; ++i){
  char *p = malloc(sizeof(char[10]));
  free(p);
}

and

for (int i=0; i<VERY_BIG_NUMBER; ++i){
  char *p = malloc(sizeof(char[10]));
  realloc(p,0);
}

With a sane implementation of malloc and free the first clip does not consume memory without bound. But if the realloc implementation returns those "minimum sized objects" it might.

Certainly this example is contrived and it relies on understanding what is meant by "minimum sized object", but I think that text allows it.

In short, if you mean free you should say free.

Macmillan answered 30/3, 2010 at 15:48 Comment(4)
I think that those implementation are NOT following the C specification. Have a look also at opengroup.org/onlinepubs/009695399/functions/realloc.htmlMenu
@munissor: This behavior is conforming. From the POSIX spec: "If size is 0, either a null pointer or a unique pointer that can be successfully passed to free() shall be returned" (emphasis mine). It is also conforming to the language in the C standard.Praedial
@munissor: I don't have my K&R handy so I can't compare to the '89 standard, but the Mac OS uses the BSD implementation which has been around for a long time. Certainly the link that James McNellis posted suggests that this behavior is allowed under the '99 standard. In any case, the results are nearly the same. (I suspect the "minimum sized object" is there to support some malloc debuggers.)Macmillan
@james, @dmkee Good to know! Never trust what you can find on Google ;)Menu
M
2

http://www.cplusplus.com/reference/clibrary/cstdlib/realloc/ says yes.

Menu answered 30/3, 2010 at 15:46 Comment(1)
This appears to contradict the C standard.Stokowski
P
1

Yes

The C99 standard §7.20.3.4 (realloc) says:

The realloc function deallocates the old object pointed to by ptr and returns a pointer to a new object that has the size specified by size. The contents of the new object shall be the same as that of the old object prior to deallocation, up to the lesser of the new and old sizes. Any bytes in the new object beyond the size of the old object have indeterminate values.

If ptr is a null pointer, the realloc function behaves like the malloc function for the specified size. Otherwise, if ptr does not match a pointer earlier returned by the calloc, malloc, or realloc function, or if the space has been deallocated by a call to the free or realloc function, the behavior is undefined. If memory for the new object cannot be allocated, the old object is not deallocated and its value is unchanged.

This clearly states that the old object is deallocated (freed). The return value might be a null pointer, or it might be a value as specified in the general notes for §7.20.3:

If the size of the space requested is zero, the behavior is implementation defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object.

Either way, you cannot dereference the value returned: it could be used as an argument to free(), or passed to other functions as long as they in turn do not reference it.

Porky answered 30/3, 2010 at 16:12 Comment(1)
It is certainly clear that the existing data is no longer accessible. But it is not clear that all the memory allocated by the original call is returned: the allocator may be maintaining a unique and non-reclaimable record for the zero sized allocation that results.Macmillan

© 2022 - 2024 — McMap. All rights reserved.