Freeing memory - will it be available immediately

[Kelsey Bjarnason]

[snips]

Where in the standard is defined that "make available by further
allocation" does not only means that free has to unblock the memory now
freed? To disallow to give the memory back to the OS there must be
something in the standard that does not explicity allow that. So where
in the standadard is required that this is the case? The standard
requires so many explicity and it woud have done that for free too - but
there is nothing about that.

Let's move this away from C for a moment. We'll examine two hypothetical
languages, Foo and Bar, each with a function baz(). In the standard
document for language Foo, the behaviour of function baz() is completely
and unequivocally defined. What does this tell us of the function baz()
in the language Bar?

Right, it tells us *nothing*. Why is that? Oh, yes, because we're not
defining baz as some universal cross-language function, we're defining it
solely and strictly within the context of the Foo language.

We can also ask what, if any, effect does Bar's definition of baz() have
upon the operation of baz in language Foo? The answer is simple: none at
all, because however Bar defines baz is irrelevant; all that matters when
using language Foo is *Foo's* definition of the function.

So let's define it:

1.1.3.5 The baz function


Synopsis:

uses IO;
intvar baz(nil);

Description:

If the end of file indicator of the standard input stream is not set and
a next character is present, baz obtains that character as an unsigned
charvar converted to an intvar and advances the associated file position
indicator, if defined.

If the end of file indicator of the standard input stream is set or if
the stream is at end of file, the end of file indicator for the stream is
set and the baz function returns EOF. Otherwise, the function returns
the next character from the standard input stream. If a read error
occurs, the error indicator for the stream is set and the baz function
returns EOF.



Very good. Now, could you kindly point out where, in that definition,
baz is either allow to or prevented from modifying every intvar variable
in the program by assigning them a value a third their current value?

Nothing in the definition of baz allows for such behaviour, obviously,
but then where is such behaviour prevented? Where does it say,
explicitly, that this is not an allowed behaviour?

It doesn't. Why should it? There is absolutely no need for it to
explicitly say this behaviour is not allowed, not because the behaviour
is allowed, but but because the definition of what baz does does *not*
include any allowance for such behaviour.

In short, the definition of baz tells us what it does, and by doing so,
implicitly prevents any other behaviour, such as modifying the values of
every intvar in the program.

Moreover, by intent, the definition of baz not only implicitly but
*explicitly* disallows such behaviour, as the intent of the document in
its entirety is to define, as absolutely as possible, the operation of
the functions and the language defined. By intent, the behaviour defined
by baz is complete and explicit: it does this *and no more*, and an
implementation which does something else - such as modifying the values
of every intvar in the program when baz is called - is thus non-
conforming.

There is no need for it to explicitly say this is a disallowed behaviour;
it is sufficient to define the behaviour that *is* allowed. It does so,
and that behaviour does *not* allow for the modification of the intvars
in the program.

Nor - and here's the apparent sticking point for some folks - does it
allow for the underlying OS, or another process, or some other factor to
modify all the intvars when baz is invoked. The behaviour defined is how
the implementation *must* behave in order to be conforming; no allowance
whatsoever is made for OS, other applications, thumb-fingered idiots or
acts of Zeus to alter this behaviour.

If the underlying system is sufficiently perverse that it *would* modify
all those intvars on an invocation of baz, it follows that the
implementer must take whatever steps necessary to preserve the existing
values of all the intvars before continuing with the operation of baz, as
failure to do so means baz is not operating in the defined manner.

In short, there is no allowance in the definition of baz for any
operation whatsoever other than that which is expressly and explicitly
defined. Even if the underlying OS is perverse, or even actively
hostile, it is the implementation's requirement to provide a baz which
works as defined and not include any extraneous behaviour outside the
scope of that definition.

Obviously, there will be some cases where this is in fact simply not
possible. If the machine loses power, the guarantees are off. If the
machine has faulty memory, variable values may be modified and baz is not
expected to cope with this. In the case of "normal operation", however -
that is, with proper power, properly functioning equipment and the like -
baz's definition simply does not allow for any behaviour other than what
it describes, such as modifying the values of all the intvars.

Yet, for some reason, we have people arguing that the definition of baz
*should* and *does* allow for such things. The reasoning? Apparently,
the reasoning is that such things are not expressly forbidden. Since baz
is not *expressly* forbidden to modify every intvar in the program, then
obviously this should be an acceptable behaviour.

To me that doesn't make any sense. To me that means the standard
document must explicitly and expressly cover every possible contingency.
It must, for example, contain clauses such as the following:

baz must not return EOF unless the standard input stream is at end of
file or an error occurs, even if the system time is 12:03:01 AM.

baz must not return EOF unless the standard input stream is at end of
file or an error occurs, even if the system date is 01/11/2008.

baz must not return EOF unless the standard input stream is at end of
file or an error occurs, even if the program's source file has 173
non-blank, non-comment lines.

baz must not return EOF unless the standard input stream is at end of
file or an error occurs, even if the programmer's name is "Fred".

Such a document would be impossible to create, impossible to maintain,
impossible to use, yet that is the very argument being offered here: that
if the behaviour is not explicitly disallowed, then it must be allowed.

I say this argument is specious. It is sufficient to define how the
function is intended to operate, with the understanding that any
operation other than the definition provided constitutes a failure, a non-
conformance condition in the implementation.

That sort of document is possible to create, to maintain, to use. In
fact, it is comparatively simple (not to belittle the efforts of the
committees); one defines the behaviour of the function(s) and any
behaviour other than what is defined, or expressly allowed by clauses
such as "implementation defined" and the like, is simply disallowed: it
works this way, or it is broken.

So let's look at free, as defined in the C standard. Where does it
explicitly disallow the function modifying the value of every int
variable in the program?

It doesn't. There is no such clause, no such allowance. Any
implementation which allowed this sort of behaviour would be regarded as
broken - yet there is no explicit disallowance of such behaviour. Why,
then, would such behaviour be considered broken? On what basis do we
determine that this is incorrect behaviour?

We determine it by the definition of free, which defines what it is
intended to do, a definition which does not involve any modification of
int variables in the program. It is not necessary to explicitly disallow
this behaviour, it is sufficient to define the intended behaviour, with
the understanding that any behaviour other than what is defined is not
permissible.

So, where do we see, in the definition of free, any explicit statement
that free cannot hand the memory back to the OS, for other purposes? We
don't. However, we don't need to, either, any more than we need to see a
guarantee that it won't modify all the int variables in the program. In
defining the guarantee between the implementation and the program, the
definition expressly states what the behaviour is, and that definition
does not include modifying every int variable in the program, nor does it
include rendering the memory _not_ available for further allocation by
the C program.

Yes, the wording used is inexplicit and in this manner one might argue
that "further allocation" includes "by the OS or another application",
except that the definition of free, the guarantees it makes, are not
being made for the OS or another application, they're being made for the
C program using the free function. There is no need for an explicit
statement against allowing the memory to be handed back to the OS; it is
sufficient to define the behaviour that is intended. Such behaviour *is*
defined, and it does not include handing the memory back to the OS,
unless the implementation can guarantee that the memory is available for
further allocation by the C program, the very thing it is making its
guarantees to.

That may not be the intent of the standard committee, but that is
irrelevant. It may be their intent that main only return an int, but if
the standard allows for main to return an array of long doubles, this is
a legal and legitimate behaviour unless and until the standard is
modified to say otherwise.

It may well be their intent that free does, in fact, return the memory
back to the OS, for further allocation "by whomever", and this is a
perfectly reasonable intent, even arguably the most sensible intent. It
is simply not a behaviour allowed by the wording as written, meaning that
unless and until changed, the standard simply does not allow such
behaviour.

 

[Keith Thompson]

I think you missed an "if" there.

void *ptr = malloc(1000);
if (ptr) { /* this isn't the one I meant, but let's check anyway */
free(ptr);
ptr = NULL;
while (1)
{
ptr = malloc(100);
if (ptr != NULL) /* this is the one I meant */
break;
}
}

I'm not convinced that this loop must terminate, but I cannot find a
sensible argument that (on a conforming implementation) it might not.

Each non-null pointer returned by malloc() must be unique. Pointers,
like all other objects, are made of bits; there are at most
2**(CHAR_BIT * sizeof(void*)) distinct void* values. Furthermore,
each byte of each allocated object has a unique address, as does the
one-past-the-end pointer, so that reduces the number of possible
unique addresses by a factor of 101.

On the other hand, the program never does anything with the pointer
other than comparing it to NULL, and never does anything at all with
the allocated space. An implementation could implicitly free() the
allocated space when it knows it will never be used, or even optimize
out the call to malloc(). Printing the value of the ptr with
``printf("%p\n", ptr);'' would inhibit this optimization and guarantee
that the loop will terminate.

 

[Keith Thompson]

[snips]
On Thu, 28 Feb 2008 02:56:07 +0000, Gordon Burditt wrote:
And this has *what* to do with the price of tea in China?

free() may return memory from the C program to the OS

Only if it can guarantee the OS will somehow tag that memory as
reserved for the C program. Otherwise, it cannot. Read the definition
of free; there is no allowance for handing the memory back to the OS in
the general case, as that would risk making the memory *not* available
for further allocation.

Proof by repetition?

One can only hope that if it is repeated often enough, the folks who seem
to think free is somehow, apparently alone of all the functions in the
entire library, not required to behave as defined, will eventually clue
in that no, sorry, the standard *does* define its behaviour and gives
*no* leeway for alternate interpretations.

I know, it gets tedious, but other than explaining it to them over and
over and over until it finally sinks in, I see no other way to get them
to grasp this rather simple point.

Nobody is claiming that free is not required to behave as defined. If
you insist of framing the argument in those terms, no progress is
possible.

A number of people disagree with your interpretation of the words in
the standard; others probably agree with you but disagree that your
interpretation is the only one possible. People aren't missing the
point; they understand your point and think you're mistaken.

Quite simply, I believe that making storage available for further
allocation by other programs qualifies as making it available for
further allocation. The standard is almost entirely devoted to
describe the behavior of a C program, but it does also talk about
interaction with the environment.

I have no problem with you claiming that your interpretation is
correct; I'm not even sure I disagree. I do have a problem with you
claiming that your interpretation is the only possible one, and
assuming that the rest of us must be blind or stupid because we
disagree.

 

[Harald van Dijk]

It does, however, mandate that
the following loop actually terminates:
[snip]

I think you missed an "if" there.

void *ptr = malloc(1000);
if (ptr) { /* this isn't the one I meant, but let's check anyway */
free(ptr);
ptr = NULL;
while (1)
{
ptr = malloc(100);
if (ptr != NULL) /* this is the one I meant */
break;
}
}

I'm not convinced that this loop must terminate, but I cannot find a
sensible argument that (on a conforming implementation) it might not.

Each non-null pointer returned by malloc() must be unique. Pointers,
like all other objects, are made of bits; there are at most 2**(CHAR_BIT
* sizeof(void*)) distinct void* values. [...]

I think you've read the check the other way around. The loop terminates as
soon as a non-null pointer value is obtained from malloc. It won't
terminate if malloc only returns null pointers, and thankfully, the null
pointers don't have to be unique.

It could be written as

do ptr = malloc(100);
while (ptr == NULL);

 

[Keith Thompson]

On Sun, 02 Mar 2008 09:52:14 -0800, Kelsey Bjarnason wrote:
It does, however, mandate that
the following loop actually terminates:
[snip]

I think you missed an "if" there.

void *ptr = malloc(1000);
if (ptr) { /* this isn't the one I meant, but let's check anyway */
free(ptr);
ptr = NULL;
while (1)
{
ptr = malloc(100);
if (ptr != NULL) /* this is the one I meant */
break;
}
}

I'm not convinced that this loop must terminate, but I cannot find a
sensible argument that (on a conforming implementation) it might not.

Each non-null pointer returned by malloc() must be unique. Pointers,
like all other objects, are made of bits; there are at most 2**(CHAR_BIT
* sizeof(void*)) distinct void* values. [...]

I think you've read the check the other way around. The loop terminates as
soon as a non-null pointer value is obtained from malloc. It won't
terminate if malloc only returns null pointers, and thankfully, the null
pointers don't have to be unique.

It could be written as

do ptr = malloc(100);
while (ptr == NULL);

Ah, you're quite right, I read it backwards. Never mind.

But if anybody else happens to ask the question I *thought* you were
asking, we have an answer already prepared.

 

[Ben Bacarisse]

[snips]

I have been sitting on my hands with this thread, but I can't any
longer. Your basis for this is that the standard only considers one
program, that there is no "OS" so how else can one interpret "being
available"?

No, that's not my basis; check the thread.

Earlier you did seem to stress the fact that the standard does nothing
but define the behaviour of one program -- that any discussion of
other entities was reading more into the words than could be there.
But I am very happy if you are not saying this. The word "allocate"
suggests exactly this: the presence of multiple entities that own the
memory -- initially something other than the program, and then the
program, once malloc has succeeded.

And nobody said anything about "to the place it came from".


Yes, and?

It can't be a debate if you do this sort of thing. The "and" comes in
the conclusion I draw in the very next sentence.

Assuming there is an OS; there need not be.

I said "entity". I apologise for the parenthetical OS reference. The
word "allocate" can be taken to be a change of ownership. That is the
point. "To assign" and "to allot" are similar.

it could be, except that the standard forbids it. The defined behaviour
of free is the defined behaviour of a C standard library function as
relied upon by a C program. The definition of that function, upon which
the program relies, says that the memory *is* made available for further
allocation. Not "may be, if the OS hasn't handed it off somewhere else",
and there is *no* clause for such implementation-defined behaviour
anywhere in the definition.

Was the memory "available for allocation" before malloc allocated it
to the program? I see that as a perfectly reasonable meaning for
those words. For free to do no more than re-create that state of
affairs seems equally reasonable. It withdraws the ownership
previously granted.

I can accept that you don't, but I am finding it hard to see why you
think it is unambiguous.

 

[Herbert Rosenau]

[snips]

In contrary to your false assumption there is nothing in the standard
that forbids to give back borrowed memory to the OS and request it from
there again when needed.

Actually, the wording of the standard forbids it. If you disagree,
please point out any part of the definition of free which allows
implementation-defined or unspecified behaviour which would allow free to
behave as you describe.

It is you job to prove that the standard forbids free to give memory
free for further allocation to whomever requests it. You failed on
that miserably until now.

You can't; it's not there. What is there is a black-and-white guarantee,
made by the C standard, about the C standard library, to the C program
and C programmer: the memory *is* made available for further allocation.

The standard is full from bans and explicit requirements. But the
request to give memory freed to further allocation does not forbid to
give memory free for further allocatin - in contrast it requires do so
so.

When it were meaning 'only to the same process' it would say that. It
says nothing about that because it lefts complete open when, if and
how the implementation has to handle 'free for further allocation'.
The only it says is 'allow that this piece of memory can be allocated
furhter.

No, what the standard does is defines the behaviour that *is* supposed to
- even guaranteed to - happen. That *defined* behaviour is what prevents
the above printing "Yes!". Just as the *defined* behaviour is what
prevents free returning the memory to the OS; the definition of free
*does not allow it* unless the implementation can *guarantee* the memory
will be made available to the program again - which, in the general case,
it cannot, meaning in the general case it *must* not return the memory to
the OS.

Furher allocation can fail because
- another thread of the same pürocess has it allocated
- another process has it allocated
- ....

Come, declare how a program can prove the difference between this 2
points that the memory can gotten because it is eaten by another
program instead of another thread. There is nothing that can prove the
difference.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

 

[Richard Tobin]

It is you job to prove that the standard forbids free to give memory
free for further allocation to whomever requests it. You failed on
that miserably until now.

I suggest giving up on this. Everyone understands everyone else's
position, and Kelsey is just being obnoxious by constantly posting
articles that ignore the previous discussion.

-- Richard

 

[user923005]

I suggest giving up on this.  Everyone understands everyone else's
position, and Kelsey is just being obnoxious by constantly posting
articles that ignore the previous discussion.

I think that either interpretation is possible. The fact there have
been long-winded discussions on this before indicate that the wording
is ambiguous.
I do not think that either side has proven their point or that the
point can (in fact) be proven.
The missing definition of what this means "The free function causes
the space pointed to by ptr to be deallocated, that is, made available
for further allocation."
clearly leaves interpretation up in the air.
The question that is nowhere answered is "Available for further
allocation by whom?"

If there were a clear definition of what this means, then the
defintion would be pointed out and the argument would be over.
I think it is madness on both sides of the argument to refuse to see
the point of the other side.
I also think it is madness to imagine that either definition is
correct, because the most important part of the definition is missing.

IMO-YMMV.

 

[santosh]

I think that either interpretation is possible. The fact there have
been long-winded discussions on this before indicate that the wording
is ambiguous.
I do not think that either side has proven their point or that the
point can (in fact) be proven.
The missing definition of what this means "The free function causes
the space pointed to by ptr to be deallocated, that is, made available
for further allocation."
clearly leaves interpretation up in the air.
The question that is nowhere answered is "Available for further
allocation by whom?"

If there were a clear definition of what this means, then the
defintion would be pointed out and the argument would be over.
I think it is madness on both sides of the argument to refuse to see
the point of the other side.
I also think it is madness to imagine that either definition is
correct, because the most important part of the definition is missing.

IMO-YMMV.

Since different systems may have different constraints the wording is,
IMO, good enough. Why does a programmer need to know where exactly the
memory has gone? As far as he is concerned, he relinquished all claims
to it when he passed it free. There is no portable way to get that same
memory block back again. It's up to the implementation to decide what
to do with the free'd memory, since only specific malloc systems would
have the knowledge of their machine to do what is best.

 

[Richard Tobin]

I suggest giving up on this.

[/QUOTE]

Well, I said that, but I'm going to respond to this posting, then stop.

I think it is madness on both sides of the argument to refuse to see
the point of the other side.

I don't think that is the situation.

Everyone except one *does* see the point of the other side, but
disagrees with it (or doesn't have an opinion either way). That's ok,
we can agree to disagree, submit a defect report, or whatever.

Kelsey on the other hand doesn't just disagree with the other side,
but refuses to acknowledge that there is any possibility of
disagreement, and just restarts the argument over and over again by
acting as if no discussion had occurred. There's no value in arguing
with someone like that.

-- Richard

 

[user923005]

Since different systems may have different constraints the wording is,
IMO, good enough. Why does a programmer need to know where exactly the
memory has gone?

Because he might want to use it again.

As far as he is concerned, he relinquished all claims
to it when he passed it free.

If that is true, then the standard should say so.

There is no portable way to get that same
memory block back again. It's up to the implementation to decide what
to do with the free'd memory, since only specific malloc systems would
have the knowledge of their machine to do what is best.

The fact that this argument exists and repeats is proof that the
standard is defective.

 

[lawrence.jones]

I think that either interpretation is possible. The fact there have
been long-winded discussions on this before indicate that the wording
is ambiguous.

And that ambiguous language was deliberately chosen to give implementors
leeway to implement it in whatever they consider to be the most useful
fashion for their user base.

-Larry Jones

Things are never quite as scary when you've got a best friend. -- Calvin

 

[Harald van Dijk]

And that ambiguous language was deliberately chosen to give implementors
leeway to implement it in whatever they consider to be the most useful
fashion for their user base.

That's surprising to me. Do you happen to know of any concrete
implementation behaviour that's permitted by the interpretation that
malloc must succeed after free, but not by the other? At any rate, I
suppose this clears things up, so thanks.

 

[user923005]

And that ambiguous language was deliberately chosen to give implementors
leeway to implement it in whatever they consider to be the most useful
fashion for their user base.

That is implementor friendly, but not friendly to users of the
document.
Something that would be friendly to both would be to spell out that
both cases are possible.

 

[santosh]

Because he might want to use it again.

The same block? If so, why free it in the first place. If he wants a
small change in size (any change in fact) then wouldn't realloc be the
way to go, instead of free followed by malloc with crossed fingers?

If that is true, then the standard should say so.

It does say so, with the word "deallocated". The confusion is with what
immediately follows, i.e., "that is, made available for further
allocation", which some programmers seem to interpret as an iron-clad
guarantee that the block is held in reserve indefinitely for the same
program.

This *is* a reasonable interpretation. It is *also* reasonable to think
that free wouldn't hold on indefinitely to large blocks of memory, but
would instead turn it over to the system, if possible.

The Standard doesn't specify either way and properly so, since this is
something that a C programmer need not worry about. It's the
implementation's job to decide on what to do. I suggest that if you
want more guarantees that you should be looking at system specific APIs
like mlock, setrlimit etc.

The fact that this argument exists and repeats is proof that the
standard is defective.

The wording is ambiguous, but since it concerns something that the
Standard provides no guarantee about (i.e., whether malloc always
succeeds, just after a free), it is not, IMO, defective. Just undefined
by omission.

 

[ymuntyan]

That is implementor friendly, but not friendly to users of the
document.
Something that would be friendly to both would be to spell out that
both cases are possible.

As a user, you have one thing pretty clear: malloc() may fail
any time it likes, even if the implementation doesn't return
anything to the OS. So that particular wording isn't friendly
or non-friendly to users.

Yevgen

 

[Herbert Rosenau]

[snips]

In contrary to your false assumption there is nothing in the standard
that forbids to give back borrowed memory to the OS and request it from
there again when needed.

Actually, the wording of the standard forbids it. If you disagree,
please point out any part of the definition of free which allows
implementation-defined or unspecified behaviour which would allow free to
behave as you describe.

Again, where in the stadard is 'make available to further allocation
only to the current program in a multiprogram environment' mentioned?
I can find only 'make available for furhter allocation by anywhom' who
can get that block' There no requirement that the block has only to
give out
- in lower size
- in bigger size
- to the same thread
- to other thread
- to the same process
- to other process
- to a driver
- never to a driver
- to the OS for internal use
- ...

The standard simple lefts unspecified who will, can, may, should (not)
do the allocation request. As it is unspecified it is left to the
implementation to define which receivers will able to recive the
memory. You faild until now to give chapter and verse the standard
forbids/denys that memory that was given once to a program can no more
given to another. That proves that you are wrong.

You can't; it's not there. What is there is a black-and-white guarantee,
made by the C standard, about the C standard library, to the C program
and C programmer: the memory *is* made available for further allocation.

You're arguing that the C standard is *not* in fact defining the
behaviour of the C standard library, that we're free to add in any random
additional crud we feel like, whenever we want, as long as it's not
*explicitly* forbidden by the standard.

So, for example, nothing in the standard *explicitly* forbids the
following from printing "Yes!":

int x = 3;

if ( ++x == 179 )
puts( "Yes!" );

There's nothing in the standard which explicitly forbids this is there?
No, there isn't. If you don't believe me, feel free to check and quote
C&V which forbids this.

You comes with complete nonsens because you fails to give chapter and
verse where the standard specifies that anything that is not explicity
allowed is forbidden.

No, what the standard does is defines the behaviour that *is* supposed to
- even guaranteed to - happen. That *defined* behaviour is what prevents
the above printing "Yes!". Just as the *defined* behaviour is what
prevents free returning the memory to the OS; the definition of free
*does not allow it* unless the implementation can *guarantee* the memory
will be made available to the program again - which, in the general case,
it cannot, meaning in the general case it *must* not return the memory to
the OS.

Now you comes and says that the stadard allows giving the now freed
memory away to anywhom who requests it as it does not forbids that
explicity - in contrast to any you've sayd before.


--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

 

[Herbert Rosenau]

[snips]

Fact is that the standard says nothing about program, nothing about an
OS, nothing about real memory, nothing about files, nothing about any
real device. It defines only an abstract mashine and its behavior from
sight of C.

Correct. Part of that definition is how free behaves, in a manner in
which a C program can rely upon. What is that definition? Oh, yes, the
memory is made available for further allocation.


Thank you for making my point so clearly.

You loves to misinterpret anything.

Again: where in the standard is 'make availble only to the same
application' mentioned?

Your loop you've desicribed in another message may run forever when
the memory is allocated by another thread of the same program. The
loop may loop 1000 years when free() allows itself to delays the
'available' 1000 years as the standard does not requires that this has
to be done immediately and even not requires that 'make available' has
to occure immediately.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

 

[user923005]

[snips]

Actually, the wording of the standard forbids it.  If you disagree,
please point out any part of the definition of free which allows
implementation-defined or unspecified behaviour which would allow free to
behave as you describe.

Again, where in the stadard is 'make available to further allocation
only to the current program in a multiprogram environment' mentioned?
I can find only 'make available for furhter allocation by anywhom' who
can get that block' There no requirement that the block has only to
give out
- in lower size
- in bigger size
- to the same thread
- to other thread
- to the same process
- to other process
- to a driver
- never to a driver
- to the OS for internal use
- ...

The standard simple lefts unspecified who will, can, may, should (not)
do the allocation request. As it is unspecified it is left to the
implementation to define which receivers will able to recive the
memory. You faild until now to give chapter and verse the standard
forbids/denys that memory that was given once to a program can no more
given to another. That proves that you are wrong.

You can't; it's not there.  What is there is a black-and-white guarantee,
made by the C standard, about the C standard library, to the C program
and C programmer: the memory *is* made available for further allocation.

You're arguing that the C standard is *not* in fact defining the
behaviour of the C standard library, that we're free to add in any random
additional crud we feel like, whenever we want, as long as it's not
*explicitly* forbidden by the standard.

So, for example, nothing in the standard *explicitly* forbids the
following from printing "Yes!":

int x = 3;

if ( ++x == 179 )
   puts( "Yes!" );

There's nothing in the standard which explicitly forbids this is there?  
No, there isn't.  If you don't believe me, feel free to check and quote
C&V which forbids this.

You comes with complete nonsens because you fails to give chapter and
verse where the standard specifies that anything that is not explicity
allowed is forbidden.

No, what the standard does is defines the behaviour that *is* supposed to
- even guaranteed to - happen.  That *defined* behaviour is what prevents
the above printing "Yes!".  Just as the *defined* behaviour is what
prevents free returning the memory to the OS; the definition of free
*does not allow it* unless the implementation can *guarantee* the memory
will be made available to the program again - which, in the general case,
it cannot, meaning in the general case it *must* not return the memory to
the OS.

Now you comes and says that the stadard allows giving the now freed
memory away to anywhom who requests it as it does not forbids that
explicity - in contrast to any you've sayd before.

Here is why I think that Kelsey has a point.
from ISO/IEC 9899:1999 (E), page 312:
"Synopsis
1 #include <stdlib.h>
void free(void *ptr);
Description
2 The free function causes the space pointed to by ptr to be
deallocated, that is, made available for further allocation."

Let's consider what is meant by the phrase "made available for further
allocation"...
If I am reading this document to understand how my program is going to
behave, "made available for further allocation" can only have one
sensible application -- how my program is going to behave. If it
really means "the memory is returned to the operating system for
further use by other programs" then it does not need to be in the
document at all. It may as well say "...that is, the memory may be
eaten by a dragon." because I cannot tell anything about how it
affects my program in the future from the statement.

So, I think if you are reading the document as a compiler writer, then
it can be interpreted as returning the memory to the operating system
for further allocation (I know of at least one compiler that *does*
retain the memory for the C program to use in the future, because
after a call to free() is made with a large block allocated, the
memory footprint for the program does not reduce). If the memory is
not made available to my program again, then it is pointless to
specify what happens to it, from the standpoint of "How will my
program behave?" which is (I suspect) the majority of the reader's of
the document's viewpoint.

I think something along the lines of:
"2 The free function causes the space pointed to by ptr to be
deallocated, that is, made available for further allocation either by
the executing C program or by other tasks requesting memory
resources." would be a better wording. It leaves both retention by
the current program or allocation by other programs as possibilities,
and does not leaving us wondering if the meaning is exclusively
either: "returned to the operating system" or "returned to the
program".

Or something along those lines.
IMO-YMMV.