Re: Freeing memory - will it be available immediately

[snips]

On Mon, 25 Feb 2008 21:53:43 -0600, Jack Klein wrote:

A literal reading of the Standard's text supports Kelsey's
interpretation, but in practise I'd expect significantly sized
deallocations to be handed back to the OS, if there was a means to do
so.

[snip]

A literal reading of the standard's text says that allocated memory
properly free'd is made available for "further allocation". It most
certainly say "further allocation by the same program".


I assume you meant "does not say" there.

Since the term
"further allocation" is not defined or constrained by the standard in
any way, where exactly does it forbid that further allocation from being
to another executable, process, device driver, etc.?

The C standard defines the expected behaviour of a C program.

The C standard, in order to do this, also defines the expected behaviour
of the standard library functions, behaviours on which that C program can
rely.

The C standard defines free as releasing the memory to be made available
for further allocation.

That's the defined operation _in the context of defining the operation of
a C program and the standard library on which it relies_. There is
nothing in that definition which allows for any other behaviour, such as
handing the memory back to the OS.

Nor, as noted elsewhere, does the "as-if" rule give us an out; failure to
make the memory available for further allocation (eg by giving it back to
the OS) is a direct violation of the text of the standard and cannot come
under the as-if rule; the as-if rule allows flexibility in conforming
behaviour, it does not allow non-conforming behaviour to take the place
of conforming.

Let's turn this on its head. You say "It most certainly does not say
'further allocation by the same program'". Very good. Explain, then,
exactly what the standard is defining the behaviour of, *if not the very
program under discussion*?

Of course it's defining the behaviour of the program and only the
program; it has no ability to define behaviours beyond that. It cannot
mandate that the system actually use a hard disk, or a monitor, it cannot
mandate that "text mode" universally means using "\r\n" so any other
applications or OSen better wake up; it defines one thing and only one
thing, the behaviour of the C program written against that standard.

In order to do so, in order to define the behaviour of the C program, it
*also* has to define the behaviours of the standard library, on which the
C program may rely. It does so, in the case of free: the memory is made
available for further allocation.

Not to the OS, not to your toaster oven, not to some other program, the C
standard has nothing to say on these matters. No, the only thing under
examination, the only candidate which the standard *can* define such
behaviours for, is the C program. It defines just such a behaviour, for
that program, and that definition absolutely precludes the notion of
handing the memory back to the OS; doing so violates the defined
behaviour of free.

.

Relevant Pages

  • Re: A solution for the allocation failures problem
    ... Can you find anything in the standard which *allows* this behaviour? ... it defines how your C program is supposed to behave. ... previously allocated memory available for further allocation. ... says the memory will be made available for further allocation. ...
    (comp.lang.c)
  • Re: Freeing memory - will it be available immediately
    ... Your interpretation of "as the standard defines it" is ... Your interpretation of "for further allocation" as "for futher ... Except that this ignores the very reason for the standard, ... return the memory back to the OS in the manner you describe. ...
    (comp.lang.c)
  • Re: malloc under linux
    ... It means what it says, i.e., even if malloc returns a non-null ... memory might not actually be allocated. ... Standard even when some other process is killed and sufficient memory is ... I can't see how the Standard does not permit lazy allocation, ...
    (comp.lang.c)
  • Re: Freeing memory - will it be available immediately
    ... Earlier you did seem to stress the fact that the standard does nothing ... further allocation" as returning the memory to the place it came from. ... word "allocate" can be taken to be a change of ownership. ...
    (comp.lang.c)
  • Re: calloc/free: a preplexing observation
    ... > that any program that writes to stdout can be strictly conforming): ... > whether lazy allocation is conforming or not, ... > The requirement for mallocis that it has to behave as the standard ... > recursive function call attempts to allocate a terabyte of memory, ...
    (comp.lang.c)