Hi,
Will 'free' return the memory Immediately to the OS ?
Thx in advans,
Karthik Balaguru
Feb 25 '08
66  3624 
On Thu, 28 Feb 2008 17:38:53 UTC, Kelsey Bjarnason
<kb********@gmail.comwrote:
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.
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.
The standard requires only that the memory shoulb be available by
further allocation - to any who requires it.
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".
But it requires that the memory is unlocked by making it available for
further allocation, not blocking it anymore from that. That's all. It
would say explicity that it is not allowed to make the memory
available for futher allocation by another program - but is requires
the further allocation absolute.
The standard lets the implementation simply the freedom to extend the
'further allocation' to other programs because it can neither forbid
nor require 'by other program' because it can't know if or if not the
implementation is able to do so.
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.
So long you can't prove by chapter and verse where the standard
forbids what it even requires 'make available for further allocation'
you are definitevely wrong by saying thet the standard forbids 'make
available by further applicatin'. It can not do so without saying that
explicity.
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.
It is you who says that 'make available for further allocation' says
'make not available for further allocation'.
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.
The explicit requirement 'make available for further allocation' means
simple 'make available for further application' and not block it from
that.
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?
You cites it: 'make available....' without any when and if, simply you
must do it but not you should do it if but never if this or that or
this or that not then - make it!
--
Tschau/Bye
Herbert
Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
On Sat, 1 Mar 2008 19:32:45 UTC, Harald van Dk <tr*****@gmail.com>
wrote:
On Sat, 01 Mar 2008 19:19:03 +0000, Herbert Rosenau wrote:
On Thu, 28 Feb 2008 18:18:01 UTC, Kelsey Bjarnason
<kb********@gmail.comwrote:
Correct, it may. It may _not_, however, fail because the
implementation chose to hand the memory freed back to the OS. The
standard forbids this, meaning that a failure in a subsequent
allocation (of the same or lesser amount of memory) is at best a QoI
issue, at worst a bug, whereas handing the memory back to the OS such
that the OS might re-use it is not merely a QoI issue or a bug, but a
non-conforming behaviour.
No, the standard requires only explicity that the block is not blocked
from further allocation. It does not forbid that free gives the block
back to the OS
unless giving the block back to the OS does not make it "available for
further allocation".
Standard library functions can only be implemented as wrappers for system
calls if those system calls meet the requirements of the standard library
functions.
So, where in the standard is defined that 'make available for further
allocation' does not mean that it means exactly what the wording 'make
available' without any when or if means exactly that and not 'make
availaable but not when the requirtement comes from....'?
So it is the freedom of the implementation to give the memory back to
the OS as it was borrowed from. Yes it does not require that the block
has to make available immediately and not even in the same size and
even not immediately to the next one. It lefts it to free when it will
give it back and lets it even define conditios internally when it
means that it should give it back to the OS. The standard requires
only 'make available for futher allocation nothing mor, nothing less.
--
Tschau/Bye
Herbert
Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
[snips]
On Thu, 28 Feb 2008 10:47:33 -0800, muntyan wrote:
Yes, malloc() and free() can be parts of a strictly conforming program.
But if a program output depends on whether implementation gives memory
back to the OS, then it's not strictly conforming. See 1) and 2).
It does *not* depend on whether the implementation gives memory back to
the OS; it depends on whether the implementation behaves as guaranteed by
the standard. If *that* makes a program non-conforming, there's no such
thing as a strictly conforming program; they *all* depend on the library
behaving as defined by the standard.
[snips]
On Sun, 02 Mar 2008 01:05:08 +0000, Herbert Rosenau wrote:
So, where in the standard is defined that 'make available for further
allocation' does not mean that it means exactly what the wording 'make
available' without any when or if means exactly that and not 'make
availaable but not when the requirtement comes from....'?
The meaning "made available for further allocation" *does* mean exactly
what it says, which is the point. It does not say "might be available
for further allocation, if the OS or another process hasn't stolen it."
The C standard defines the behaviour of C programs, part of which is
defining the behaviour of the C standard library in a manner those
programs can rely on. In defining this, it includes a definition of the
behaviour of free, a C standard library function, which a C program is
_supposed_ to be able to rely upon working as defined - and that
definition says the memory is "made available for further allocation".
It's a _C_ library function guarantee to a _C_ language program. Free
either meets this guarantee or is broken.
[snips]
On Sat, 01 Mar 2008 19:19:03 +0000, Herbert Rosenau wrote:
On Wed, 27 Feb 2008 00:53:19 UTC, Kelsey Bjarnason
<kb********@gmail.comwrote:
Yes, no!. Increment and decrement is well specified by the standard. For
variables are not pointers it is always 1.
[snip irrelevant crud having absolutely nothing to do with the case at
hand, which involved variables of type int]
>Therefore, by defining a behaviour for free, the standard defines what
free is expected to do, how it is expected to behave.
No, it does this only partially. It does not specify - should a single
block coming back from the program
[snip irrelevant crud which is purely implementation details, having
nothing to do with the guarantees offered by the definition of free]
It only requests explicity that a block that comes in from free should
NOT holded in use anymore but has to be given free for further
allocation for any c|m|realloc from who ever.
No, not "from who ever". From the C program, the very thing the standard
is defining the behaviour of.
You can't have it both ways. Either the standard defines the behaviour
of a C program (and attendant details such as the C standard library) in
which case "who ever" doesn't apply, the *only* candidate for
consideration is the C program in question, or the standard does *not*
define the behaviour of a C program, in which case we may as well scrap
it as it is no use whatsoever in determining how a C program is supposed
to work.
More formally, it defines the C language, rather than the specific
program, but the effect is the same: when writing a program, one is
*supposed* to be able to deduce, by comparing the code to the standard,
the intended behaviour at least of the constructs involved; obviously the
actual data being processed will alter the program flow, but again in a
manner which is supposed to be deterministic, based upon the standard.
If that is true, if the C standard defines the C language, defines the
intended behaviour of the constructs within a C program and thus of the
program itself, then the definition of free, being part of that standard,
defines how free is supposed to work *for the C program*. It does, and
that definition does *not* allow the memory to be reallocated by
"whomever"; it *requires* it to be reallocatable by the C program.
Again, you can't have it both ways; either it defines the behaviour of
the C program, in which case there is *no* leeway given for "whomever",
or it doesn't define the behaviour of the C program, so we'll have to
look elsewhere to see how C programs are intended to behave. What would
you suggest? A VB reference? The ADA standard? Something else?
[snips]
On Thu, 28 Feb 2008 10:35:16 -0800, muntyan wrote:
Exactly, it defines the behavior of strictly conforming programs. So
provide an example of a strictly conforming program whose behavior can
be affected by malloc() giving memory back to OS
The example relies upon the implementation behaving as defined by the
standard. You're arguing that a program is not strictly conforming
because an *implementation* does something other than the standard
requires.
By this argument, there is no such thing as a strictly conforming
program, as one can trivially create an implementation which violates the
requirements of the standard on any arbitrary portion of the program's
operation.
It's silly, spurious, specious argument.
On Fri, 29 Feb 2008 07:22:37 +0000, Richard Bos wrote:
Kelsey Bjarnason <kb********@gmail.comwrote:
>Do, please, show me
No. You cannot be shown anything while your eyes and mind are closed.
Goodbye.
"Goodbye", as an indicator of a complete and abject failure to make a
point, is an indicator of an open mind and open eyes?
[snips]
On Sat, 01 Mar 2008 19:19:03 +0000, Herbert Rosenau wrote:
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.
[snips]
On Fri, 29 Feb 2008 11:11:24 -0500, lawrence.jones wrote:
The committee has discussed this issue in the past and the consensus was
that returning the memory to the OS *does* make it available for future
allocation.
Obviously it does; it simply does so in a manner not allowed by the
standard, which defines the behaviour of free in a manner the C program
can rely upon: in this case, that the memory *is* made available for
further allocation.
If the memory is handed back to the OS, then it might never be available
for further allocation to the C program and the guarantee made by the
definition of free is violated.
>The committee has discussed this issue in the past and the consensus was
>that returning the memory to the OS *does* make it available for future
allocation.
Obviously it does; it simply does so in a manner not allowed by the
standard, which defines the behaviour of free in a manner the C program
can rely upon: in this case, that the memory *is* made available for
further allocation.
If the memory is handed back to the OS, then it might never be available
for further allocation to the C program and the guarantee made by the
definition of free is violated.
Not true if the OS only hands the memory to programs the OS can
guarantee the OS can get the memory back from (this would include
non-C programs that can be subject to a OOM killer).
On Sun, 02 Mar 2008 12:05:15 -0800, Keith Thompson wrote:
Harald van Dijk <tr*****@gmail.comwrites:
>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);
Harald van Dijk <tr*****@gmail.comwrites:
On Sun, 02 Mar 2008 12:05:15 -0800, Keith Thompson wrote:
>Harald van Dijk <tr*****@gmail.comwrites:
>>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.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
In article <wm***************************@JUPITER1.PC-ROSENAU.DE>,
Herbert Rosenau <os****@pc-rosenau.dewrote:
>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
--
:wq
On Mar 3, 9:04*am, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <wmzsGguTDN6N-pn2-erog4WhxG...@JUPITER1.PC-ROSENAU.DE>,
Herbert Rosenau <os2...@pc-rosenau.dewrote:
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.
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.
In article <3f**********************************@s19g2000prg. googlegroups.com>,
user923005 <dc*****@connx.comwrote:
>I suggest giving up on this.
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
--
:wq
user923005 <dc*****@connx.comwrote:
>
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
On Mon, 03 Mar 2008 16:35:47 -0500, lawrence.jones wrote:
user923005 <dc*****@connx.comwrote:
>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.
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Adrian |
last post by:
Hi
I have a JS program that runs localy (under IE6 only) on a PC but it has
a memory leak (probably the known MS one!)
What applications are there that I could use to look at the memory usage of...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
