realloc(p, 0)

[copx]

Is realloc(p, 0) a valid operation or does it cause undefined behaviour?
Can you still free(p) after this?
Even if it's valid do you think compiler writers actually thought of this
case?

 

[Peter Nilsson]

Is realloc(p, 0) a valid operation

Yes.

"If size is zero and ptr is not a null pointer, the object
it points to is freed."

Use a reference like N869 if you don't have the standard.

or does it cause undefined behaviour?
Can you still free(p) after this?
No.

Even if it's valid do you think compiler writers actually
thought of this case?

No, but standard library authors _must_, if they want to claim
compliance.

 

[copx]

Yes.

"If size is zero and ptr is not a null pointer, the object
it points to is freed."

Use a reference like N869 if you don't have the standard.


No, but standard library authors _must_, if they want to claim
compliance.

Thanks for the info!

copx

 

[Christopher Benson-Manica]

Is realloc(p, 0) a valid operation or does it cause undefined behaviour?

It is valid.

http://www.eskimo.com/~scs/C-faq/q7.30.html

Can you still free(p) after this?
No.

Even if it's valid do you think compiler writers actually thought of this
case?

Probably most modern compiler writers did. YMMV.

 

[Keith Thompson]

It is valid.

http://www.eskimo.com/~scs/C-faq/q7.30.html


No.

That depends on how you invoke it.

If you just call

realloc(p, 0);

and ignore the returned value, p will be a pointer to deallocated
memory, and free(p) (or any ues of p) will invoke undefined behavior.

If you call it like this:

p = realloc(p, 0);

then the value of p will be either a null pointer or a valid pointer;
in either case, you can safely call free(p).

 

[Christopher Benson-Manica]

That depends on how you invoke it.

True; I just figured OP was asking about the case where you can't,
since he didn't seem to be checking the return value of realloc().