By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,978 Members | 1,362 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,978 IT Pros & Developers. It's quick & easy.

Freeing memory - will it be available immediately

P: n/a
Hi,

Will 'free' return the memory Immediately to the OS ?

Thx in advans,
Karthik Balaguru

Feb 25 '08 #1
Share this Question
Share on Google+
66 Replies


P: n/a
karthikbalaguru wrote:
Hi,

Will 'free' return the memory Immediately to the OS ?
I believe Harold Pinter, when directing plays he wrote, would answer
questions about the characters, their motivation and so on by saying
"the text doesn't tell us"...

That's the answer here...
Feb 25 '08 #2

P: n/a
On 25 Feb, 09:10, karthikbalaguru <karthikbalagur...@gmail.comwrote:
Will 'free' return the memory Immediately to the OS ?
usually no. In fact usually the memory is only returned to the OS
when the program terminates. But this is all implementation
dependent.

--
Nick Keighley
"but that's the worse thing that could possibly happen!
but it's worse than that!"

an engineer on hearing of a fault
Feb 25 '08 #3

P: n/a
On Feb 25, 2:10 pm, karthikbalaguru <karthikbalagur...@gmail.com>
wrote:
Hi,

Will 'free' return the memory Immediately to the OS ?

Thx in advans,
Karthik Balaguru
No and yes, but usually no. The standard library implementation may
not release the acquired memory to the OS. However, the program can
not use it anymore once freed.

Thanks,
Vijay Zanvar
http://faq.zanvar.in
Feb 25 '08 #4

P: n/a
On Mon, 25 Feb 2008 01:10:49 -0800, karthikbalaguru wrote:
Hi,

Will 'free' return the memory Immediately to the OS ?
The proper answer is that, according to the text of the standard, it
*cannot* return the memory to the OS; the definition of free simply does
not allow this.

That said, there are a lot of badly broken implementations out there
which do, in fact, return the memory to the OS, despite this making them
completely non-conforming. As to how _soon_ they do this, only the
implementer knows for certain.

Feb 25 '08 #5

P: n/a
[snips]

On Mon, 25 Feb 2008 16:43:10 +0530, santosh wrote:
I think you are misunderstanding what freeing immediately actually
means. In fact the standard has nothing to say about when it is freed
and it could mean many things in many systems. I would guess that free
would remove the memory from the allocated list and add it to the free
list, at a minimum. This has to be done. Whether it also returns the
memory to the OS, i.e., shrinks the data segment of the process, is
totally implementation specific.
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.

If you can find "implementation defined" in the definition of free, in a
manner which would allow the behaviour you describe, please quote it; I
cannot find it anywhere.

Feb 25 '08 #6

P: n/a
In article <e2***********@spanky.localhost.net>,
Kelsey Bjarnason <kb********@gmail.comwrote:
>This has to be done. Whether it also returns the
memory to the OS, i.e., shrinks the data segment of the process, is
totally implementation specific.
>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.
Those who didn't follow the recent thread on the subject should note
that this is merely a theory recently advanced by Kelsey; it does not
reflect any consensus on the subject; it is contrary to previous
interpretation of the standard; and at most implies the need for a
correction to the standard, rather than having any implication for
users or implementors of C.

-- Richard

--
:wq
Feb 25 '08 #7

P: n/a
Kelsey Bjarnason wrote:
[snips]

On Mon, 25 Feb 2008 16:43:10 +0530, santosh wrote:
>I think you are misunderstanding what freeing immediately actually
means. In fact the standard has nothing to say about when it is freed
and it could mean many things in many systems. I would guess that
free would remove the memory from the allocated list and add it to
the free list, at a minimum. This has to be done. Whether it also
returns the memory to the OS, i.e., shrinks the data segment of the
process, is totally implementation specific.

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.
I said implementation specific, not implementation defined, meaning
possibly non-conforming behaviour by implementations. From the POV of
the Standard, I suppose one can say that it is undefined by omission
whether free returns the memory to the OS, if any, or not. Thus they
(the implementations) can do whatever they like, as long as they
fullfill the wording of malloc and free in the Standard.

The following program demonstrates how at least one implementation (gcc
4.1.0 under Linux 2.6.15) *does* return the allocated memory back to
the OS after free has been called on it.

code:
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <limits.h>

#define DEFAULT_SIZE 134217728UL

int main(int argc, char **argv) {
size_t memsize;
unsigned char *ptr;

if (argc 1) {
unsigned long tmp;
errno = 0;
tmp = strtoul(argv[1], NULL, 0);
if (tmp == ULONG_MAX && errno == ERANGE) {
puts("Value too large...");
exit(EXIT_FAILURE);
}
else memsize = (size_t)tmp;
}
else memsize = (size_t)DEFAULT_SIZE;

printf("Attempting to allocate %lu bytes...\n",
(unsigned long)memsize);
ptr = malloc(memsize);
puts("Press Enter to proceed:");
getchar();
free(ptr);
puts("Press Enter to exit:");
getchar();
return EXIT_SUCCESS;
}

$ gcc -Wall -Wextra -ansi -pedantic -o t1 t1.c
$ ./t1 1000000000
Attempting to allocate 1000000000 bytes...
Press Enter to proceed:

Here is the output of 'ps aux | grep t1'
santosh 28617 0.0 0.0 977984 396 pts/2 S+ 07:29 0:00 ./t1
1000000000

Press Enter to exit:

Here is the output of the same command after free had been called:
santosh 28617 0.0 0.0 1420 396 pts/2 S+ 07:29 0:00 ./t1
1000000000

$

As you can see, memory is indeed "given back" to the OS after it has
been deallocated. Granted this may not happen for smaller amounts, but
this seems to happen at least with glibc and probably most other
implementations as well.

If the majority of implementations do in fact do this, then I'd say that
it is the Standard that may need to be modified rather than force
inconvenient behaviour on systems, something that C goes to great
lengths to avoid.

<snip>

Feb 26 '08 #8

P: n/a
Kelsey Bjarnason wrote:
On Mon, 25 Feb 2008 01:10:49 -0800, karthikbalaguru wrote:
>Hi,

Will 'free' return the memory Immediately to the OS ?

The proper answer is that, according to the text of the standard, it
*cannot* return the memory to the OS; the definition of free simply does
not allow this.
According to your interpretation of the somewhat ambiguous phrase "made
available for further allocation".

--
Ian Collins.
Feb 26 '08 #9

P: n/a
Ian Collins said:
Kelsey Bjarnason wrote:
>On Mon, 25 Feb 2008 01:10:49 -0800, karthikbalaguru wrote:
>>Hi,

Will 'free' return the memory Immediately to the OS ?

The proper answer is that, according to the text of the standard, it
*cannot* return the memory to the OS; the definition of free simply does
not allow this.
According to your interpretation of the somewhat ambiguous phrase "made
available for further allocation".
....which is a perfectly reasonable interpretation, and one that I would
fully expect implementors to support. (Whether my expectations are
actually met in the Real World is an entirely different matter!)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Feb 26 '08 #10

P: n/a
Richard Heathfield wrote:
Ian Collins said:
>Kelsey Bjarnason wrote:
>>On Mon, 25 Feb 2008 01:10:49 -0800, karthikbalaguru wrote:

Hi,

Will 'free' return the memory Immediately to the OS ?
The proper answer is that, according to the text of the standard, it
*cannot* return the memory to the OS; the definition of free simply does
not allow this.
According to your interpretation of the somewhat ambiguous phrase "made
available for further allocation".

....which is a perfectly reasonable interpretation, and one that I would
fully expect implementors to support. (Whether my expectations are
actually met in the Real World is an entirely different matter!)
It may be a reasonable interpretation, but it isn't definitive. So
Kelsey's answer can't claim to be "The proper answer", merely one
possible answer.

--
Ian Collins.
Feb 26 '08 #11

P: n/a
Ian Collins wrote:
Richard Heathfield wrote:
>Ian Collins said:
>>Kelsey Bjarnason wrote:
On Mon, 25 Feb 2008 01:10:49 -0800, karthikbalaguru wrote:

Hi,
>
Will 'free' return the memory Immediately to the OS ?
The proper answer is that, according to the text of the standard,
it *cannot* return the memory to the OS; the definition of free
simply does not allow this.

According to your interpretation of the somewhat ambiguous phrase
"made available for further allocation".

....which is a perfectly reasonable interpretation, and one that I
would fully expect implementors to support. (Whether my expectations
are actually met in the Real World is an entirely different matter!)
It may be a reasonable interpretation, but it isn't definitive. So
Kelsey's answer can't claim to be "The proper answer", merely one
possible answer.
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. *I* wouldn't want to use any implementation that fails to return
deallocated memory of significant size (say 100 Mb) back to the OS, if
at all possible. It's poor QoI and selfish behaviour in a timesharing
environment.

However such behaviour may be perfectly acceptable under single user,
embedded and realtime systems. This is why, I suspect, the Standard has
declined to specify a concrete behaviour and intentionally left the
wording neutral.

Feb 26 '08 #12

P: n/a
On Mon, 25 Feb 2008 13:54:54 -0800, Kelsey Bjarnason
<kb********@gmail.comwrote in comp.lang.c:
[snips]

On Mon, 25 Feb 2008 16:43:10 +0530, santosh wrote:
I think you are misunderstanding what freeing immediately actually
means. In fact the standard has nothing to say about when it is freed
and it could mean many things in many systems. I would guess that free
would remove the memory from the allocated list and add it to the free
list, at a minimum. This has to be done. Whether it also returns the
memory to the OS, i.e., shrinks the data segment of the process, is
totally implementation specific.

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.
Chapter and verse, please, I insist. What wording in the C standard
prohibits free() from returning memory to the operating system?
If you can find "implementation defined" in the definition of free, in a
manner which would allow the behaviour you describe, please quote it; I
cannot find it anywhere.
It is not implementation-defined, it is indeed unspecified. The one
and only statement in the standard that speaks about memory
deallocated by free() is (in C99) the first sentence of paragraph 2 of
7.20.3.2: "The free function causes the space pointed to by ptr to be
deallocated, that is, made available for further allocation."

What, in this wording, says that the space must be available for
further allocation by the program that free'd it?

What, in this wording, prohibits the implementation, which includes
the host OS in a hosted environment, from making that memory space
available to another process/program/component?

Since the standard does not define or constrain "further allocation",
how can you claim it forbids the second example?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Feb 26 '08 #13

P: n/a
On Tue, 26 Feb 2008 08:44:13 +0530, santosh <sa*********@gmail.com>
wrote in comp.lang.c:
Ian Collins wrote:
Richard Heathfield wrote:
Ian Collins said:

Kelsey Bjarnason wrote:
On Mon, 25 Feb 2008 01:10:49 -0800, karthikbalaguru wrote:

Hi,

Will 'free' return the memory Immediately to the OS ?
The proper answer is that, according to the text of the standard,
it *cannot* return the memory to the OS; the definition of free
simply does not allow this.

According to your interpretation of the somewhat ambiguous phrase
"made available for further allocation".

....which is a perfectly reasonable interpretation, and one that I
would fully expect implementors to support. (Whether my expectations
are actually met in the Real World is an entirely different matter!)
It may be a reasonable interpretation, but it isn't definitive. So
Kelsey's answer can't claim to be "The proper answer", merely one
possible answer.

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". 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.?

As already said, Kelsey's interpretation is reasonable, but by no
means either guaranteed or required by the actual wording of the
standard.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Feb 26 '08 #14

P: n/a
Kelsey Bjarnason <kb********@gmail.comwrote:
On Mon, 25 Feb 2008 16:43:10 +0530, santosh wrote:
I think you are misunderstanding what freeing immediately actually
means. In fact the standard has nothing to say about when it is freed
and it could mean many things in many systems. I would guess that free
would remove the memory from the allocated list and add it to the free
list, at a minimum. This has to be done. Whether it also returns the
memory to the OS, i.e., shrinks the data segment of the process, is
totally implementation specific.

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.

Richard
Feb 26 '08 #15

P: n/a
On Tue, 26 Feb 2008 07:25:14 +0000, Richard Bos wrote:
Kelsey Bjarnason <kb********@gmail.comwrote:
>On Mon, 25 Feb 2008 16:43:10 +0530, santosh wrote:
I think you are misunderstanding what freeing immediately actually
means. In fact the standard has nothing to say about when it is freed
and it could mean many things in many systems. I would guess that
free would remove the memory from the allocated list and add it to
the free list, at a minimum. This has to be done. Whether it also
returns the memory to the OS, i.e., shrinks the data segment of the
process, is totally implementation specific.

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 - you know, the
part where it says "implementation defined" or "undefined" or even
"unspecified" in the definition of free.

You can't; it's not there. What is there is a clear and absolute
definition of how free behaves in the context of a C program, the very
thing the standard exists to define. What is that behaviour? Oh, yes,
the memory is made available for further allocation. In what context?
Oh, yes, in the context of defining the behaviour of the C program.

It's pretty clear, there is, as far as I can tell, simply no other way to
read the definition of free, *in context*, and come to any other
conclusion.

You say I'm wrong? Fine; show me. Show me where the definition of free
gives it *any* allowance, via undefined, unspecified or implementation
defined clauses, to behave other than as the standard says it does.

Feb 26 '08 #16

P: n/a
Kelsey wrote:
) One needs to consider context. The C standard defines the behaviour of a
) C program, which in turn means it also defines how the standard library
) functions define _as relates to that C program_.

I believe this is the point of contention.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
Feb 26 '08 #17

P: n/a
[snips]

On Tue, 26 Feb 2008 08:44:13 +0530, santosh 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. *I* wouldn't want to use any implementation that fails to return
deallocated memory of significant size (say 100 Mb) back to the OS, if
at all possible. It's poor QoI and selfish behaviour in a timesharing
environment.
Ooh, no, I would *not* want such a setup either. If I free memory, I
would much rather have it go back into the pool for all applications to
use; this strikes me as the most reasonable possible behaviour. It's
simply not a behaviour allowed by the standard.

Feb 26 '08 #18

P: n/a
Kelsey wrote:
) Ooh, no, I would *not* want such a setup either. If I free memory, I
) would much rather have it go back into the pool for all applications to
) use; this strikes me as the most reasonable possible behaviour. It's
) simply not a behaviour allowed by the standard.

So all you're really saying is that the wording used in the standard
is not quite what it should be.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
Feb 26 '08 #19

P: n/a
On Mon, 25 Feb 2008 09:10:49 UTC, karthikbalaguru
<ka***************@gmail.comwrote:
Will 'free' return the memory Immediately to the OS ?
There is nothing that says that an block given back fpr forther
allocation may given back to the OS. It belongs onnly to the
application if free() will
- reserve the memor< freed only for another malloc() of the same
program
- given back immediately to the OS
- only given back to the OS when sone other condition(s) are fullifyed

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
Feb 26 '08 #20

P: n/a
On Tue, 26 Feb 2008 17:01:11 UTC, Kelsey Bjarnason
<kb********@gmail.comwrote:
On Tue, 26 Feb 2008 07:25:14 +0000, Richard Bos wrote:
Kelsey Bjarnason <kb********@gmail.comwrote:
On Mon, 25 Feb 2008 16:43:10 +0530, santosh wrote:

I think you are misunderstanding what freeing immediately actually
means. In fact the standard has nothing to say about when it is freed
and it could mean many things in many systems. I would guess that
free would remove the memory from the allocated list and add it to
the free list, at a minimum. This has to be done. Whether it also
returns the memory to the OS, i.e., shrinks the data segment of the
process, is totally implementation specific.

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 - you know, the
part where it says "implementation defined" or "undefined" or even
"unspecified" in the definition of free.
So the standard proklamates that on an implementation is only one
single program exists, as it says nothing about what a program is, how
a program can be started or ended. It says nothing about interprocess
communication, files, printers and even devices.

At least a single program in context of standard means that there is
no operating system at all. So free() has to make free'd memory ready
to get allocated again and not blocked from allocation further. It
does never forbid to give memory< back to the OS as there is no OS
known by the standard. It does explicity require that that block of
memory can be allocated later (by anyone who can allocate it (even
other programs - because the standard does not even know that other
program can exist.

The standard is describing an abstract mashine that knows nothing
about
- memory
- CPU
- OS
- keyboard
- mouse
- printer
- screen
- any other real existent device
- programs
- DLLs
- libraries
- linker
- compiler
- debugger

So, come on and reconnoite how the standard will allow or dedy
something about something it knows not even that it (can) exist.

So the standard lefts still open what it measn by "another allocation"
other than the next request of malloc(), realloc() or calloc() should
get the now freed block again when it requests a region of memory. As
it can't differ between processes or threads because it knows not that
they amy (or even my not) exist on an real implementation it lefts
this open to the implementation give the freed memory to the next
instance that requests it.

The standard is menticulous exact in describing the language - but
extremly lax outside that to allow an implementationb to define what
it needs. So free()ing memory means give that memory to the next who
requests it, not definitely the same program, the same thread but
simply the next call that needs it. And not even the next in sequence.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
Feb 26 '08 #21

P: n/a
On Mon, 25 Feb 2008 21:57:07 UTC, Kelsey Bjarnason
<kb********@gmail.comwrote:
On Mon, 25 Feb 2008 01:10:49 -0800, karthikbalaguru wrote:
Hi,

Will 'free' return the memory Immediately to the OS ?

The proper answer is that, according to the text of the standard, it
*cannot* return the memory to the OS; the definition of free simply does
not allow this.

That said, there are a lot of badly broken implementations out there
which do, in fact, return the memory to the OS, despite this making them
completely non-conforming. As to how _soon_ they do this, only the
implementer knows for certain.
Again, where is the stadard forbidding free() to release memory for
further allocation()? Chapter and verse, please.

How will the standard forbid another malloc() to request a block of
free space?

Remeber that the standard simply knows not that on the mashine
something like processes exists?

You likes here to say that malloc() should never reuse free'd memory
only because it was some time ago used. The standard does nowhere
speak about a process and usage of memory.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
Feb 26 '08 #22

P: n/a
On Tue, 26 Feb 2008 17:23:52 +0000, Willem wrote:
Kelsey wrote:
) One needs to consider context. The C standard defines the behaviour
of a ) C program, which in turn means it also defines how the standard
library ) functions define _as relates to that C program_.

I believe this is the point of contention.
Oh? The C standard has been extended to defining the behaviour of OSen
and toasters, cars and cabbages? When did this happen? Last I checked,
it defined C, or, more specifically, the behaviour of a C program.

Feb 27 '08 #23

P: n/a
>>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.
Nowhere does the standard distinguish between freed memory that is held
by the program vs. memory that has been returned to the OS.
>Chapter and verse, please, I insist. What wording in the C standard
prohibits free() from returning memory to the operating system?

One needs to consider context. The C standard defines the behaviour of a
C program, which in turn means it also defines how the standard library
functions define _as relates to that C program_.

The definition of free says that the memory freed is made available for
further allocation.
Tell me what prohibits this implementation:

One block of physical memory is not distinguishable from another
block. It is not necessary that the same physical memory block be
made available for reallocation, as long as a block to replace it
is. Presuming the implementation has memory-mapping hardware,
contiguity of physical blocks is not an issue, as they can be mapped
to be contiguous in virtual space even if the physical blocks aren't.

A C program may free memory and the implementation may return it
to the OS. The OS may then let a non-C program (or a C program
running in non-standard-compliant mode) have it. If the C program
subsequently wants it back, the OS will _wait until it is available_,
for as long as necessary, then give it back.

Now all I have to do is prove this won't result in deadlocks involving
the C program of interest. The implementation will run only one C
program in standards mode at a time, although that program may run
others with system(). *Other* programs may get refused memory
because of possible deadlock. The C program may get refused memory
if it's asking for more memory than it ever had before. If only
non-C-standard-mode programs and programs not run by C-standard-mode
programs get killed when the system gets bitten by overcommitting
memory, there's no violation of the requirements of the standard.
>Thus, in context, it defines, _for the C program_ that the memory remains
available; it cannot, therefore, hand it back to the OS, as the memory
would then _not_ be available for further allocation.
Yes, it would, if it's possible to eventually get it back, regardless
of how long it takes, as long as it's less than infinite time.
>It is not implementation-defined, it is indeed unspecified.

Actually, it is quite clearly defined, absolutely and unequivocally.
Feb 27 '08 #24

P: n/a
On Tue, 26 Feb 2008 19:12:42 +0000, Willem wrote:
Kelsey wrote:
) Ooh, no, I would *not* want such a setup either. If I free memory, I
) would much rather have it go back into the pool for all applications
to ) use; this strikes me as the most reasonable possible behaviour.
It's ) simply not a behaviour allowed by the standard.

So all you're really saying is that the wording used in the standard is
not quite what it should be.
I *suspect* the intent of "made available for further allocation" is "by
any process which requests it" or some such - i.e. *do* hand it back to
the OS and let it sort out who gets it. The wording, as written, just
doesn't allow this. If that is the intent, the wording is incorrect; if
that's not the intent, if the wording is correct, then I suspect there's
a whole lot of non-conforming implementations out there.

Feb 27 '08 #25

P: n/a
Kelsey Bjarnason wrote:
>
.... snip ...
>
If I'm wrong, please point out the clause which allows the defined
behaviour to work other than as the standard defines it - you know,
the part where it says "implementation defined" or "undefined" or
even "unspecified" in the definition of free.

You can't; it's not there. What is there is a clear and absolute
definition of how free behaves in the context of a C program, the
very thing the standard exists to define. What is that behaviour?
Oh, yes, the memory is made available for further allocation. In
what context? Oh, yes, in the context of defining the behaviour of
the C program.
However, according to the standard, there is no other C program
competing. Thus the problem cannot arise.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Feb 27 '08 #26

P: n/a
>I *suspect* the intent of "made available for further allocation" is "by
>any process which requests it" or some such - i.e. *do* hand it back to
the OS and let it sort out who gets it.
Suppose for the moment that it really does mean "made available for
further allocation by *THIS* program", but it does not mean "made
available for further *immediate* allocation by *THIS* program".
If the memory is not now available, WAIT UNTIL IT IS.

(and if you hit a deadlock, the C-standard-mode program isn't the one
to get killed or have malloc() fail).
>The wording, as written, just
doesn't allow this.
Yes, it does. Wait for the other program that got the memory to
finish, then give it to the C program of concern. There is nothing
in the standard that says that malloc() can't take years to get the
memory back.
>If that is the intent, the wording is incorrect; if
that's not the intent, if the wording is correct, then I suspect there's
a whole lot of non-conforming implementations out there.
There probably are. And you probably have to limit the system to
running at most one C-standard-mode program and an arbitrary number
of non-C-standard-mode programs simultaneously.

Feb 27 '08 #27

P: n/a
On Feb 25, 2:21 pm, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <e2qb95-og....@spanky.localhost.net>,
Kelsey Bjarnason <kbjarna...@gmail.comwrote:
This has to be done. Whether it also returns the
memory to the OS, i.e., shrinks the data segment of the process, is
totally implementation specific.
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.

Those who didn't follow the recent thread on the subject should note
that this is merely a theory recently advanced by Kelsey
This is not an accurate statement, in that the theory is neither
recent, nor
original to Kelsey. While watching this thread, I've had the
very strong feeling that I'd seen Kelsey's argument before, and that
it was
accepted by respected regulars to this list (which was why I was
somewhat
surprised to find it largely spurned by the same).

It appears I'm right: Lawrence Kirby and Dan Pop both held this
opinion, or at
least held it to be quite credible. The standards committee was asked
about it,
and the reply was that returning memory to the system is permitted:

http://groups.google.com/group/comp....10e07d4d24034d

For my part, I believe I quite agree with Pop's summary of the
situation:

From http://groups.google.com/group/comp....93163a9fa6033d :
>>If free() gives the memory block back to the system, you may not be able
to get it back, so it was not made available for further allocation.
>>void free(void *x){} dosen't make it available for further allocation :)

Indeed (and I thought, for years, that such an implementation would be
non-conforming). Unfortunately, the committee members didn't mean "made
available for further allocation" when they wrote "made available
for further allocation". Don't ask me what they actually meant ;-(
Lawrence Kirby also has something to say about it, way back in 1996:
http://groups.google.com/group/comp....56cb7e08d330f9

(Back to Richard Tobin):
it does not
reflect any consensus on the subject; it is contrary to previous
interpretation of the standard; and at most implies the need for a
correction to the standard, rather than having any implication for
users or implementors of C.
All of these, in light of the above, appear to remain accurate. While
we may
lament the rather poor wording of the Standard, perhaps given that the
committee
has clarified the matter, we can let it drop? :)
Feb 27 '08 #28

P: n/a
Micah Cowan wrote:
This is not an accurate statement, in that the theory is neither
recent, nor
original to Kelsey. While watching this thread, I've had the
very strong feeling that I'd seen Kelsey's argument before, and that
it was
accepted by respected regulars to this list (which was why I was
somewhat
surprised to find it largely spurned by the same).
Arg. Apologies for the nasty formatting. I guess I wasn't confident that
Google would break my lines, so I did it by hand, which was apparently
shooting myself in the foot.

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
Feb 27 '08 #29

P: n/a
On Feb 26, 5:20*pm, Micah Cowan <mi...@cowan.namewrote:
Micah Cowan wrote:
This is not an accurate statement, in that the theory is neither
recent, nor
original to Kelsey. While watching this thread, I've had the
very strong feeling that I'd seen Kelsey's argument before, and that
it was
accepted by respected regulars to this list (which was why I was
somewhat
surprised to find it largely spurned by the same).

Arg. Apologies for the nasty formatting. I guess I wasn't confident that
Google would break my lines, so I did it by hand, which was apparently
shooting myself in the foot.
The links you provided are adequate proof that even experts are not
agreed on as to the definite meaning of the wording.

I think that the DR should have been followed through. After all,
here we are in a big debate again over the same thing.

I guess that three years hence we will see another cycle. When it is
something as important as "How does this computer language work?" it
seems to me that we should make it totally unambiguous.

IMO-YMMV
Feb 27 '08 #30

P: n/a
user923005 wrote:
On Feb 26, 5:20 pm, Micah Cowan <mi...@cowan.namewrote:
>Micah Cowan wrote:
>>This is not an accurate statement, in that the theory is neither
recent, nor
original to Kelsey. While watching this thread, I've had the
very strong feeling that I'd seen Kelsey's argument before, and that
it was
accepted by respected regulars to this list (which was why I was
somewhat
surprised to find it largely spurned by the same).
Arg. Apologies for the nasty formatting. I guess I wasn't confident that
Google would break my lines, so I did it by hand, which was apparently
shooting myself in the foot.

The links you provided are adequate proof that even experts are not
agreed on as to the definite meaning of the wording.

I think that the DR should have been followed through. After all,
here we are in a big debate again over the same thing.

I guess that three years hence we will see another cycle. When it is
something as important as "How does this computer language work?" it
seems to me that we should make it totally unambiguous.
Well, given that my system, a commonly-used development platform,
violates the standard's guarantees wrt allocated memory in a rather more
egregious way - namely, to allow malloc() to return a pointer, and then
decide later, upon that pointer's use, whether it should actually make
memory available through that pointer or simply kill the process for
attempting to use a "valid" pointer... the text of the standard in this
matter ends up not distressing me too much, given that, any way you look
at it, my implementation's busted. :)

(I'm speaking, of course, of Linux's OOM killer.)

Still, yeah, seems like it should be addressed. By someone other than
me, of course - I'm too lazy. ;)

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
Feb 27 '08 #31

P: n/a
Herbert Rosenau wrote:

<snip>
So, look on:

1 mashine will run only one single program. This single program
(commonly known as operation system) loads many different extensions -
you sees them as differen programs, but they are nothing else than
plugins like modern browsers use to extend theyr abilities.
This isn't true for microkernel based systems and those with
virtualisation.

<snip>

Feb 27 '08 #32

P: n/a
Kelsey Bjarnason <kb********@gmail.comwrote:
On Tue, 26 Feb 2008 07:25:14 +0000, Richard Bos wrote:
Kelsey Bjarnason <kb********@gmail.comwrote:
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.

Richard
Feb 27 '08 #33

P: n/a
[snips]

On Wed, 27 Feb 2008 00:27:10 +0000, Gordon Burditt wrote:
Tell me what prohibits this implementation:
[irrelevances snipped]
A C program may free memory and the implementation may return it to the
OS. The OS may then let a non-C program (or a C program running in
non-standard-compliant mode)
Non-conforming mode? Yes, well, you just answered your question: you're
using a non-conforming implementation, which means it's either broken, or
non-conforming by intent; if the former, file a bug report. If the
latter, consider it a QoI issue.

Feb 27 '08 #34

P: n/a
On Wed, 27 Feb 2008 10:19:59 +0000, Richard Bos wrote:
Kelsey Bjarnason <kb********@gmail.comwrote:
>On Tue, 26 Feb 2008 07:25:14 +0000, Richard Bos wrote:
Kelsey Bjarnason <kb********@gmail.comwrote:

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?

Feb 27 '08 #35

P: n/a
On Wed, 27 Feb 2008 00:44:02 +0000, Gordon Burditt wrote:
>>Correct; *if* the memory is available, there's no problem. However, the
implementation cannot guarantee that this will be the case; the OS may
well hand the memory off to some other process.

There's nothing wrong with that unless the memory is handed off to some
other process *PERMANENTLY*.
Which it may well be. Since the implementation is *required* to make the
memory available for further allocation, it cannot therefore rely on the
OS which may well hand that memory off to something else until the end of
time.
>>Thus, to be conforming,
the implementation *cannot* hand the memory back to the OS; it must
retain it, reserve it, for further allocation by the program.
No, if the C program wants it back, the OS can simply wait until the
memory is available again.
Which it may never be, thus violating the requirements of the standard.

Feb 27 '08 #36

P: n/a
On Tue, 26 Feb 2008 20:46:19 +0000, Herbert Rosenau wrote:
On Mon, 25 Feb 2008 21:57:07 UTC, Kelsey Bjarnason
<kb********@gmail.comwrote:
>On Mon, 25 Feb 2008 01:10:49 -0800, karthikbalaguru wrote:
Hi,

Will 'free' return the memory Immediately to the OS ?

The proper answer is that, according to the text of the standard, it
*cannot* return the memory to the OS; the definition of free simply
does not allow this.

That said, there are a lot of badly broken implementations out there
which do, in fact, return the memory to the OS, despite this making
them completely non-conforming. As to how _soon_ they do this, only
the implementer knows for certain.
Again, where is the stadard forbidding free() to release memory for
further allocation()? Chapter and verse, please.
Actually, that is what the standard *defines* free as doing - releasing
memory for further allocation.

If you mean where does it define free as not being allowed to return the
memory back to the OS, one merely needs to ask what the C standard is
defining. As far as I can tell, it is defining the behaviour of a C
program, and the behaviour of the standard library upon which that
program is built.

Part of that defined behaviour is that the memory released by free is
made available for further allocation.

That guarantee, however, is made *in the context* of defining the
behaviour of a C program and the standard library on which the C program
relies.

Feb 27 '08 #37

P: n/a
>Tell me what prohibits this implementation:
>
[irrelevances snipped]
>A C program may free memory and the implementation may return it to the
OS. The OS may then let a non-C program (or a C program running in
non-standard-compliant mode)

Non-conforming mode? Yes, well, you just answered your question: you're
using a non-conforming implementation, which means it's either broken, or
non-conforming by intent; if the former, file a bug report. If the
latter, consider it a QoI issue.
An implementation only has to run *ONE* standard-conforming C program
at a time, but it can run other stuff non-conforming. Anything
else it runs need not be written in C. The C standard only applies
to the (only) program written in C and running in standard-conforming
mode.

In other words, the C program running in standard-conforming mode
must be immune to the Linux OOM killer. Other programs need not be.

Feb 28 '08 #38

P: n/a
On Thu, 28 Feb 2008 00:48:17 +0000, Gordon Burditt wrote:
>>Tell me what prohibits this implementation:

[irrelevances snipped]
>>A C program may free memory and the implementation may return it to
the OS. The OS may then let a non-C program (or a C program running
in non-standard-compliant mode)

Non-conforming mode? Yes, well, you just answered your question: you're
using a non-conforming implementation, which means it's either broken,
or non-conforming by intent; if the former, file a bug report. If the
latter, consider it a QoI issue.

An implementation only has to run *ONE* standard-conforming C program at
a time, but it can run other stuff non-conforming.
And this has *what* to do with the price of tea in China?

Feb 28 '08 #39

P: n/a
>>>Tell me what prohibits this implementation:
>>>
[irrelevances snipped]

A C program may free memory and the implementation may return it to
the OS. The OS may then let a non-C program (or a C program running
in non-standard-compliant mode)

Non-conforming mode? Yes, well, you just answered your question: you're
The C standard imposes no constraints on the way the OS handles non-C
programs. It only applies to programs running as standard C programs.
>>>using a non-conforming implementation, which means it's either broken,
or non-conforming by intent; if the former, file a bug report. If the
latter, consider it a QoI issue.
An implementation of C is not broken because the OS runs non-C programs
differently from the way it runs C programs.
>An implementation only has to run *ONE* standard-conforming C program at
a time, but it can run other stuff non-conforming.

And this has *what* to do with the price of tea in China?
free() may return memory from the C program to the OS, and the OS
may reallocate the memory to a non-C program, and the OS may forcibly
take back the memory using a Linux OOM killer (if needed), and give
it back to the original C program, all without violating any
requirement of the C standard, which applies only to the original
C program and not to other non-C programs the OS may be running at
the same time.

Feb 28 '08 #40

P: n/a
Kelsey Bjarnason <kb********@gmail.comwrote:
On Wed, 27 Feb 2008 10:19:59 +0000, Richard Bos wrote:
Kelsey Bjarnason <kb********@gmail.comwrote:
On Tue, 26 Feb 2008 07:25:14 +0000, Richard Bos wrote:

Kelsey Bjarnason <kb********@gmail.comwrote:

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.
Others' interpretation of "for further allocation" as "for futher
allocation by any program" is also a reasonable one.
Your refusal to accept the others' interpretation as reasonable is
unreasonable; your interpretation of "for further allocation" as "for
futher allocation by the current program alone, and no other
interpretation is acceptable" is simply wrong.
Richard
Feb 28 '08 #41

P: n/a
[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.

Feb 28 '08 #42

P: n/a
On Thu, 28 Feb 2008 12:33:16 +0000, Richard Bos wrote:
Kelsey Bjarnason <kb********@gmail.comwrote:
>On Wed, 27 Feb 2008 10:19:59 +0000, Richard Bos wrote:
Kelsey Bjarnason <kb********@gmail.comwrote:

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

Kelsey Bjarnason <kb********@gmail.comwrote:

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?

Feb 28 '08 #43

P: n/a
In article <ts************@spanky.localhost.net>,
Kelsey Bjarnason <kb********@gmail.comwrote:
>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.
As you surely know by now from the statements made by committee members
in the thread Micah Cowan referred us to:

http://groups.google.com/group/comp....10e07d4d24034d

your interpretation is a misinterpretation. Instead of pretending that
your misinterpretation takes precedence over what we know to be intended,
why not submit a Defect Report asking them to clarify the wording so
that others don't make your mistake?

-- Richard
--
:wq
Feb 28 '08 #44

P: n/a
On Feb 28, 11:38 am, Kelsey Bjarnason <kbjarna...@gmail.comwrote:
On Thu, 28 Feb 2008 12:33:16 +0000, Richard Bos wrote:
Kelsey Bjarnason <kbjarna...@gmail.comwrote:
On Wed, 27 Feb 2008 10:19:59 +0000, Richard Bos wrote:
Kelsey Bjarnason <kbjarna...@gmail.comwrote:
On Tue, 26 Feb 2008 07:25:14 +0000, Richard Bos wrote:
Kelsey Bjarnason <kbjarna...@gmail.comwrote:
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".
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
(and yes, failing to allocate that big block again) or stop
waving the standard like a flag. Note the "example of a strictly
conforming program" part. Everybody heard already that the standard
says there in black and white... not toasters and cars... etc.
Feb 28 '08 #45

P: n/a
Kelsey Bjarnason <kb********@gmail.comwrote:
Do, please, show me
No. You cannot be shown anything while your eyes and mind are closed.

Goodbye.

Richard
Feb 29 '08 #46

P: n/a
Kelsey Bjarnason <kb********@gmail.comwrote:
>
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.
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. The fact that it may not remain available for very long is
outside the scope of the standard, as is the amount of memory that is
available for allocation at any particular point in time.

-Larry Jones

I like Mom to be impressed when I fulfill the least of my obligations.
-- Calvin
Feb 29 '08 #47

P: n/a
On Thu, 28 Feb 2008 18:47:33 UTC, mu*****@gmail.com 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).
Where in the stadndard is the requirement that the whole malloc family
is not only a number of wrappers around OS APIs?

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
Mar 1 '08 #48

P: n/a
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.
Mar 1 '08 #49

P: n/a
"Herbert Rosenau" <os****@pc-rosenau.dewrites:
On Thu, 28 Feb 2008 18:47:33 UTC, mu*****@gmail.com 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).

Where in the stadndard is the requirement that the whole malloc family
is not only a number of wrappers around OS APIs?
Obviously there's no such requirement; malloc, free, and friends are
simply required to behave in accordance with the standard's
requirements. I don't think anyone has implied otherwise.

Suppose the OS provides a system call sys_alloc(). If sys_alloc()
happens to satisfy the requirements for malloc(), then malloc() can be
a simple wrapper. (Or, for efficiency, malloc() might use various
techniques to avoid the overhead of a system call on each malloc()
call.) But if sys_alloc(), say, doesn't guarantee that the allocated
chunk is properly aligned, then malloc() *can't* be a simple wrapper.

Note that, whether the standard *allows* free() to return storage to
the OS or not, it certainly doesn't *require* it to do so. An
implementation in which free() always hoards allocated memory for the
exclusive use of the current program would be conforming. (Whether it
should is, at least partly, a QoI issue.)

--
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"
Mar 1 '08 #50

66 Replies

This discussion thread is closed

Replies have been disabled for this discussion.