1:
It is not possible to check EVERY malloc result within complex software.
2:
The reasonable solution (use a garbage collector) is not possible for
whatever reasons.
3:
A solution like the one proposed by Mr McLean (aborting) is not
possible for software quality reasons. The program must decide
if it is possible to just abort() or not.
Solution:
1) At program start, allocate a big buffer that is not used
elsewhere in the program. This big buffer will be freed when
a memory exhaustion situation arises, to give enough memory
to the error reporting routines to close files, or otherwise
do housekeeping chores.
2) xmalloc()
static int (*mallocfailedHandler)(int);
void *xmalloc(size_t nbytes)
{
restart:
void *r = malloc(nbytes);
if (r)
return r;
// Memory exhaustion situation.
// Release some memory to the malloc/free system.
if (BigUnusedBuffer)
free(BigUnusedBuffer);
BigUnusedBuffer = NULL;
if (mallocfailedHandler == NULL) {
// The handler has not been set. This means
// this application does not care about this
// situation. We exit.
fprintf(stderr,
"Allocation failure of %u bytes\n",
nbytes);
fprintf(stderr,"Program exit\n");
exit(EXIT_FAILURE);
}
// The malloc handler has been set. Call it.
if (mallocfailedHandler(nbytes)) {
goto restart;
}
// The handler failed to solve the problem.
// Exit without any messages.
exit(EXIT_FAILURE);
}
4:
Using the above solution the application can abort if needed, or
make a long jump to a recovery point, where the program can continue.
The recovery handler is supposed to free memory, and reallocate the
BigUnusedBuffer, that has been set to NULL;
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Jan 29 '08
158  5945 
[snips]
On Tue, 12 Feb 2008 09:38:37 +0000, Richard Tobin wrote:
>>It *is*, however, sufficient to define what the C program can expect,
and it does so, right there. In defining the behaviour of free in the
only context which it *can* define things - that of the program - it
expressly says the memory will be made available for further allocation.
Again, you're the only one who interprets it that way.
Because that's what it says, in black and white.
As you say, the standard can't be expected to define the details of the
operating system. If it can't do that, and it can't prevent memory
being returned to the operating system without talking explicitly about
the operating system, you are led to the absurd conclusion that a
programming language standard *can't* allow memory to be return to the
operating system.
No, I'm led to the conclusion that the standard, which defines the
behaviour of a C program, actually *defines the behaviour of a C
program*. Part of that definition, right there in black and white, is
that free releases the memory for subsequent allocation.
That is the behaviour defined, that is the behaviour defined *in defining
the behaviour of a C program*.
[snips]
On Tue, 12 Feb 2008 06:42:06 +0000, Richard Heathfield wrote:
Kelsey makes the most convincing case I have ever read for
implementations being required to make freed memory available to the
program.
Well, thank you for that, but for some reason consensus seems to be
"Never mind what the standard says, ignore than and do what it means,
instead" - without stopping to realize that the only way we can determine
"what it means" is from "what it says".
Oh well. Someone, somewhere, other than me might at some point care that
the wording and the intention are completely at odds with each other. I
give up.
Morris Dovey said:
Kelsey Bjarnason wrote:
<snip>
>Oh well. Someone, somewhere, other than me might at some point care
that
the wording and the intention are completely at odds with each other. I
give up.
Don't give up. Take the problem to c.l.c.m and suggest that a
clearer statement is appropriate.
IMHO this belongs in comp.std.c, since it's a discussion about the Standard
rather than the language.
IMO, there shouldn't be a need to debate the /meaning/ of the standard.
Agreed - so when there is such a need (i.e. when people who are fairly
conversant with the Standard can't agree about what it means), it is an
indication that the Standard is, or at least may be, at fault.
--
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
Kelsey Bjarnason <kb********@gmail.comwrites:
[snips]
On Tue, 12 Feb 2008 09:38:37 +0000, Richard Tobin wrote:
>>>It *is*, however, sufficient to define what the C program can expect,
and it does so, right there. In defining the behaviour of free in the
only context which it *can* define things - that of the program - it
expressly says the memory will be made available for further allocation.
Again, you're the only one who interprets it that way.
Because that's what it says, in black and white.
>As you say, the standard can't be expected to define the details of the
operating system. If it can't do that, and it can't prevent memory
being returned to the operating system without talking explicitly about
the operating system, you are led to the absurd conclusion that a
programming language standard *can't* allow memory to be return to the
operating system.
No, I'm led to the conclusion that the standard, which defines the
behaviour of a C program, actually *defines the behaviour of a C
program*. Part of that definition, right there in black and white, is
that free releases the memory for subsequent allocation.
That is the behaviour defined, that is the behaviour defined *in defining
the behaviour of a C program*.
That's not the only way to interpret the black and white wording of
the standard.
free() makes the space "available for further allocation". If the
space is made available for further allocation *by other programs*,
then it's been made available for further allocation.
Similarly, when a program creates a file, that file becomes available
for use by other programs; another program opening the file might make
it unavailable to the current program. Would you argue that that
behavior would violate the standard?
Over in comp.std.c, Doug Gywn, a member of the ISO C committee, has
said that memory deallocated by free() can be reclaimed by the OS (you
can find the article for his exact words). I'm not saying his
statement has the force of law, but it does imply something about the
intent. In my opinion, the words of the standard are uncomfortably
ambiguous, but they are consistent with the intent.
--
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"
Richard Heathfield wrote:
IMHO this belongs in comp.std.c, since it's a discussion about the Standard
rather than the language.
Oops/thanks! (Having trouble saying what I mean [not a good
sign])
--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA http://www.iedu.com/DeSoto
Richard Heathfield <rj*@see.sig.invalidwrites:
Morris Dovey said:
>Kelsey Bjarnason wrote:
<snip>
>>Oh well. Someone, somewhere, other than me might at some point
care that the wording and the intention are completely at odds
with each other. I give up.
Don't give up. Take the problem to c.l.c.m and suggest that a
clearer statement is appropriate.
IMHO this belongs in comp.std.c, since it's a discussion about the Standard
rather than the language.
[...]
Agreed -- which is why I started a thread there, with the subject
"available for further allocation"?
--
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"
Kelsey Bjarnason wrote, On 12/02/08 18:40:
[snips]
On Tue, 12 Feb 2008 06:42:06 +0000, Richard Heathfield wrote:
>Kelsey makes the most convincing case I have ever read for
implementations being required to make freed memory available to the
program.
Well, thank you for that, but for some reason consensus seems to be
"Never mind what the standard says, ignore than and do what it means,
instead" - without stopping to realize that the only way we can determine
"what it means" is from "what it says".
No, there is another way. You can raise a DR to query the standards body.
Oh well. Someone, somewhere, other than me might at some point care that
the wording and the intention are completely at odds with each other. I
give up.
Another point is that is does not say that it is made available for
allocation by malloc/calloc/realloc. So if the program uses one byte of
the space that was freed to allocate space for a char variable and thus
does not have the full amount available for allocation with malloc is it
non-conforming? There have been implementations where the stack grows
towards the heap, so it is possible.
--
Flash Gordon
Keith Thompson wrote:
>
Kelsey Bjarnason <kb********@gmail.comwrites:
[...]
No, I'm led to the conclusion that the standard, which defines the
behaviour of a C program, actually *defines the behaviour of a C
program*. Part of that definition, right there in black and white, is
that free releases the memory for subsequent allocation.
That is the behaviour defined, that is the behaviour defined *in defining
the behaviour of a C program*.
That's not the only way to interpret the black and white wording of
the standard.
free() makes the space "available for further allocation". If the
space is made available for further allocation *by other programs*,
then it's been made available for further allocation.
I believe Kelsey's argument (and I'm sure he'll correct me if I'm
wrong) is that the Standard doesn't acknowledge the existence of
"other programs", and therefore any "further allocation" would by
necessity refer to "the current program".
The problem, as others have pointed out, is the ambiguity of the
statement as worded. If the memory were to be made "available for
further allocation" by "another program", have you violated the
Standard or not?
[...]
Over in comp.std.c, Doug Gywn, a member of the ISO C committee, has
said that memory deallocated by free() can be reclaimed by the OS (you
can find the article for his exact words). I'm not saying his
statement has the force of law, but it does imply something about the
intent. In my opinion, the words of the standard are uncomfortably
ambiguous, but they are consistent with the intent.
I think this is a case for comp.std.c's input, though I am hardly
an expert in such matters.
Now, suppose you were to have a memory manager implementation where
free space is grouped according to the size of the block. For
example, less than 2K, 2K to 4K, 4K to 8K, and so on. When the
free(block_of_60K) call is made, the memory is put in the 32K to
64K pool. Now, further suppose that this memory manager were very
poorly written, such that when malloc(10000) is called, and the
8K to 16K pool is full, it does not bother checking the larger
pools. Finally, suppose that it asks the O/S for more memory and
this call fails.
Is this implementation non-conforming, or is it simply a very poor
(yet still conforming) implementation? After all, the memory has
been made "available for further allocation", as any malloc() in
the 32K to 60K range would have succeeded.
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
In article <7q************@spanky.localhost.net>,
Kelsey Bjarnason <kb********@gmail.comwrote:
>Well, thank you for that, but for some reason consensus seems to be
"Never mind what the standard says, ignore than and do what it means,
instead" - without stopping to realize that the only way we can determine
"what it means" is from "what it says".
No. If that were the case, I doubt you could interpret it at all.
The standard is written in English, and relies on a huge amount of
background knowledge about computers as well as the everyday pragmatic
interpretation of English.
You yourself are using a (rather bizarre) pragmatic rule in your own
interpretation: that because the standard does not acknowledge the
existence of other programs, then we must interpret everything as if
there weren't another program. This rule is doubly wrong: the
standard does acknowledge the existence of other programs (for
example, do you think it would bother providing files otherwise?), and
the inference itself it not justified either by common sense or
explicit wording in the standard.
-- Richard
--
:wq This thread has been closed and replies have been disabled. Please start a new discussion. |
