Re: Freeing memory - will it be available immediately

On Thu, 28 Feb 2008 12:33:16 +0000, Richard Bos wrote:

Kelsey Bjarnason <kbjarnason@xxxxxxxxx> wrote:

On Wed, 27 Feb 2008 10:19:59 +0000, Richard Bos wrote:

Kelsey Bjarnason <kbjarnason@xxxxxxxxx> wrote:

On Tue, 26 Feb 2008 07:25:14 +0000, Richard Bos wrote:

Kelsey Bjarnason <kbjarnason@xxxxxxxxx> wrote:

Is it? I see nothing whatsoever in the definition of free which
allows for any implementation-defined behaviour; its behaviour,
quite the contrary, is absolutely and clearly defined, and *does
not permit* handing the memory back to the OS.

You keep opining that, and you continue to be wrong.

If I'm wrong, please point out the clause which allows the defined
behaviour to work other than as the standard defines it

There is none. Your interpretation of "as the standard defines it" is
wrong.

You keep saying that, why is it you seem unable to demonstrate it?

It's been explained several times, but you refuse to accept it.

One (one last!) more time:

Your interpretation of "for further allocation" as "for futher
allocation by the current program alone" is a reasonable one.

Since the very thing whose behaviour is being defined is the C program,
it is the *only* relevant context in which to define the behaviour.

Others'
interpretation of "for further allocation" as "for futher allocation by
any program" is also a reasonable one.

Except that this ignores the very reason for the standard, which is *not*
to define behaviours of "any program".

Your refusal to accept the
others' interpretation as reasonable is unreasonable;

On the contrary, it is perfectly reasonable, as they have yet to give any
justification for this magical intrusion of the rest of the world into
the operation of free, contrary to the dictates of the standard, and
apparently alone of all the standard library functions.

The fact they cannot justify this means they cannot claim their position
*is* justified, therefore they have no argument.

So again, how about *showing* I'm wrong, rather than simply hand-waving?
Show me where, in the standard's definition of free, it allows *any* form
of implementation-defined behaviour or the like which allows free to
return the memory back to the OS in the manner you describe.

You can't. It's not there. What is there is a guarantee that the memory
is made available for further allocation, a guarantee made in defining
the behaviours and expectations of a C program.

Do, please, show me the clause which allows the behaviour you describe,
as it's not to be found in the definition of free. Nor anywhere else as
far as I can tell. You've obviously found such a clause, why can't you
quote it?

.

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: 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)
  • Re: Can I Increase size of nNoMansLandSize?
    ... look at memory, I see that in the "no man's land" that the debug memory ... allocation creates, one of the DWORDs has been changed to 0x0000001. ... I can't find any rhyme or reason to when this happens, ... I can't find any other way to tap into the new/debug scheme. ...
    (microsoft.public.vc.mfc)