«

It's a simple question..... can the free() function sometimes fail??

sandeep <> writes:

> It's a simple question..... can the free() function sometimes fail??

No.
--
Ben Pfaff
http://benpfaff.org

"sandeep" <> wrote in message
news:htmq7n$bej$...
> It's a simple question..... can the free() function sometimes fail??

It can sometimes give undefined behaviour with invalid input (according to
the docs). But it doesn't return any status or set any error code.

--
Bartc

sandeep <> writes:
> It's a simple question..... can the free() function sometimes fail??

Yes, but it can do so only in cases where the program's behavior
is undefined, which is why it has no mechanism for reporting failure.

For example:

int *p = malloc(sizeof *p); /* assume this succeded */
free(p); /* ok */
free(p); /* undefined behavior */

Another example:

int i;
int *p = &i;
free(p); /* undefined behavior */

I suppose it's debatable whether the undefined free() calls "fail";
it might be more accurate to say that the program failed by calling
free() with an invalid argument.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 5/27/2010 6:03 PM, sandeep wrote:
> It's a simple question..... can the free() function sometimes fail??

It depends on what you mean by "fail."

If you mean "attempt an operation and report whether the operation
was or was not carried out," the answer is No. That is, free() cannot
"fail" the way malloc() can, or fopen(), or even the way strchr() can.

If you include "exhibit undefined behavior" in your definition of
"fail," then the answer is Yes. If you try to free() something not
obtained from malloc() et al., or free() something more than once, or
scribble on your memory, or invoke U.B. somewhere else in the program,
the entire program -- including free() -- exhibits U.B.

--
Eric Sosman
lid

On 2010-05-27, Eric Sosman <> wrote:
> On 5/27/2010 6:03 PM, sandeep wrote:
>> It's a simple question..... can the free() function sometimes fail??

> It depends on what you mean by "fail."

> If you mean "attempt an operation and report whether the operation
> was or was not carried out," the answer is No. That is, free() cannot
> "fail" the way malloc() can, or fopen(), or even the way strchr() can.

> If you include "exhibit undefined behavior" in your definition of
> "fail," then the answer is Yes. If you try to free() something not
> obtained from malloc() et al., or free() something more than once, or
> scribble on your memory, or invoke U.B. somewhere else in the program,
> the entire program -- including free() -- exhibits U.B.

The most interesting question, I think, is:

Can there ever be a valid input to free(), such that the implementation
cannot actually free the memory? I can easily describe an implementation
in which this could be the case. You could construct an implementation in
which there was some sort of "free list" which could require allocation
in order to add items to that list, and if you had precisely filled available
memory, it could be that you couldn't free something because there'd be no
way to add it to the available-things list.

That would be an unusual implementation, at best, but I'm not sure that it
is prohibited.

Of course, there'd be no way to find OUT that this had happened.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 2010-05-28, Keith Thompson <kst-> wrote:
> Well, it would violate the requirement that "The free function causes
> the space pointed to by ptr to be deallocated, that is, made available
> for further allocation." (C99 7.20.3.2p2), so one could argue that
> it would be as non-conforming as this implementation:

> But yes, as long as there are no visible symptoms of the failure,
> it can't be detected. (Failure of later allocations doesn't count,
> since that can happen for any arbitrary reasons.)

Exactly. I'm not sure how you could tell. It seems like it'd be a pretty
bad implementation, but...

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs <usenet-> writes:
[...]
> The most interesting question, I think, is:
>
> Can there ever be a valid input to free(), such that the implementation
> cannot actually free the memory? I can easily describe an implementation
> in which this could be the case. You could construct an implementation in
> which there was some sort of "free list" which could require allocation
> in order to add items to that list, and if you had precisely filled available
> memory, it could be that you couldn't free something because there'd be no
> way to add it to the available-things list.
>
> That would be an unusual implementation, at best, but I'm not sure that it
> is prohibited.
>
> Of course, there'd be no way to find OUT that this had happened.

Well, it would violate the requirement that "The free function causes
the space pointed to by ptr to be deallocated, that is, made available
for further allocation." (C99 7.20.3.2p2), so one could argue that
it would be as non-conforming as this implementation:

void free(void *ptr)
{
/* nyaah nyaah! */
}

But yes, as long as there are no visible symptoms of the failure,
it can't be detected. (Failure of later allocations doesn't count,
since that can happen for any arbitrary reasons.)

Practically speaking, of course, the implementation could use the
space being freed to hold any bookkeeping data for the free list,
but implementations aren't required to behave sanely.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

sandeep wrote:
> It's a simple question..... can the free() function sometimes fail??
Just give it a mangled pointer, and try it.

On May 28, 6:25*am, Keith Thompson <ks...@mib.org> wrote:
> sandeep <nos...@nospam.com> writes:
> > It's a simple question..... can the free() function sometimes fail??
>
> Yes, but it can do so only in cases where the program's behavior
> is undefined, which is why it has no mechanism for reporting failure.
>
> For example:
>
> * * int *p = malloc(sizeof *p); /* assume this succeded */
> * * free(p); /* ok */
> * * free(p); /* undefined behavior */
>
> Another example:
>
> * * int i;
> * * int *p = &i;
> * * free(p); /* undefined behavior */
>
> I suppose it's debatable whether the undefined free() calls "fail";
> it might be more accurate to say that the program failed by calling
> free() with an invalid argument.
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org *<http://www.ghoti.net/~kst>
> Nokia
> "We must do something. *This is something. *Therefore, we must do this."
> * * -- Antony Jay and Jonathan Lynn, "Yes Minister"

Good reply.