«

In article <3fdeeead-d3e4-4d73-abae->,
user923005 <> wrote:

>> 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

On Mar 3, 1:07*pm, santosh <santosh....@gmail.com> wrote:
> user923005 wrote:
> > 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.de> wrote:
> >> >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.
>
> Since different systems may have different constraints the wording is,
> IMO, good enough. Why does a programmer need to know where exactly the
> memory has gone?

Because he might want to use it again.

> As far as he is concerned, he relinquished all claims
> to it when he passed it free.

If that is true, then the standard should say so.

> There is no portable way to get that same
> memory block back again. It's up to the implementation to decide what
> to do with the free'd memory, since only specific malloc systems would
> have the knowledge of their machine to do what is best.

The fact that this argument exists and repeats is proof that the
standard is defective.

user923005 <> wrote:
>
> 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 <> wrote:
>> 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.

On Mar 3, 1:35*pm, lawrence.jo...@siemens.com wrote:
> user923005 <dcor...@connx.com> wrote:
>
> > 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 is implementor friendly, but not friendly to users of the
document.
Something that would be friendly to both would be to spell out that
both cases are possible.

user923005 wrote:

> On Mar 3, 1:07*pm, santosh <santosh....@gmail.com> wrote:
>> user923005 wrote:
>> > 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.de> wrote:
>> >> >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.
>>
>> Since different systems may have different constraints the wording
>> is, IMO, good enough. Why does a programmer need to know where
>> exactly the memory has gone?
>
> Because he might want to use it again.

The same block? If so, why free it in the first place. If he wants a
small change in size (any change in fact) then wouldn't realloc be the
way to go, instead of free followed by malloc with crossed fingers?

>> As far as he is concerned, he relinquished all claims
>> to it when he passed it free.
>
> If that is true, then the standard should say so.

It does say so, with the word "deallocated". The confusion is with what
immediately follows, i.e., "that is, made available for further
allocation", which some programmers seem to interpret as an iron-clad
guarantee that the block is held in reserve indefinitely for the same
program.

This *is* a reasonable interpretation. It is *also* reasonable to think
that free wouldn't hold on indefinitely to large blocks of memory, but
would instead turn it over to the system, if possible.

The Standard doesn't specify either way and properly so, since this is
something that a C programmer need not worry about. It's the
implementation's job to decide on what to do. I suggest that if you
want more guarantees that you should be looking at system specific APIs
like mlock, setrlimit etc.

>> There is no portable way to get that same
>> memory block back again. It's up to the implementation to decide what
>> to do with the free'd memory, since only specific malloc systems
>> would have the knowledge of their machine to do what is best.
>
> The fact that this argument exists and repeats is proof that the
> standard is defective.

The wording is ambiguous, but since it concerns something that the
Standard provides no guarantee about (i.e., whether malloc always
succeeds, just after a free), it is not, IMO, defective. Just undefined
by omission.

On Mar 3, 6:14 pm, user923005 <dcor...@connx.com> wrote:
> On Mar 3, 1:35 pm, lawrence.jo...@siemens.com wrote:
>
> > user923005 <dcor...@connx.com> wrote:
>
> > > 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 is implementor friendly, but not friendly to users of the
> document.
> Something that would be friendly to both would be to spell out that
> both cases are possible.

As a user, you have one thing pretty clear: malloc() may fail
any time it likes, even if the implementation doesn't return
anything to the OS. So that particular wording isn't friendly
or non-friendly to users.

Yevgen

On Sun, 2 Mar 2008 18:18:16 UTC, Kelsey Bjarnason
<> wrote:

> [snips]
>
> On Sat, 01 Mar 2008 19:19:03 +0000, Herbert Rosenau wrote:
>
> > In contrary to your false assumption there is nothing in the standard
> > that forbids to give back borrowed memory to the OS and request it from
> > there again when needed.
>
> Actually, the wording of the standard forbids it. If you disagree,
> please point out any part of the definition of free which allows
> implementation-defined or unspecified behaviour which would allow free to
> behave as you describe.

Again, where in the stadard is 'make available to further allocation
only to the current program in a multiprogram environment' mentioned?
I can find only 'make available for furhter allocation by anywhom' who
can get that block' There no requirement that the block has only to
give out
- in lower size
- in bigger size
- to the same thread
- to other thread
- to the same process
- to other process
- to a driver
- never to a driver
- to the OS for internal use
- ...

The standard simple lefts unspecified who will, can, may, should (not)
do the allocation request. As it is unspecified it is left to the
implementation to define which receivers will able to recive the
memory. You faild until now to give chapter and verse the standard
forbids/denys that memory that was given once to a program can no more
given to another. That proves that you are wrong.

> You can't; it's not there. What is there is a black-and-white guarantee,
> made by the C standard, about the C standard library, to the C program
> and C programmer: the memory *is* made available for further allocation.
>
> You're arguing that the C standard is *not* in fact defining the
> behaviour of the C standard library, that we're free to add in any random
> additional crud we feel like, whenever we want, as long as it's not
> *explicitly* forbidden by the standard.
>
> So, for example, nothing in the standard *explicitly* forbids the
> following from printing "Yes!":
>
> int x = 3;
>
> if ( ++x == 179 )
> puts( "Yes!" );
>
> There's nothing in the standard which explicitly forbids this is there?
> No, there isn't. If you don't believe me, feel free to check and quote
> C&V which forbids this.

You comes with complete nonsens because you fails to give chapter and
verse where the standard specifies that anything that is not explicity
allowed is forbidden.

> No, what the standard does is defines the behaviour that *is* supposed to
> - even guaranteed to - happen. That *defined* behaviour is what prevents
> the above printing "Yes!". Just as the *defined* behaviour is what
> prevents free returning the memory to the OS; the definition of free
> *does not allow it* unless the implementation can *guarantee* the memory
> will be made available to the program again - which, in the general case,
> it cannot, meaning in the general case it *must* not return the memory to
> the OS.

Now you comes and says that the stadard allows giving the now freed
memory away to anywhom who requests it as it does not forbids that
explicity - in contrast to any you've sayd before.


--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

On Sun, 2 Mar 2008 18:20:19 UTC, Kelsey Bjarnason
<> wrote:

> [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.
>
You loves to misinterpret anything.

Again: where in the standard is 'make availble only to the same
application' mentioned?

Your loop you've desicribed in another message may run forever when
the memory is allocated by another thread of the same program. The
loop may loop 1000 years when free() allows itself to delays the
'available' 1000 years as the standard does not requires that this has
to be done immediately and even not requires that 'make available' has
to occure immediately.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

On Mar 4, 3:12*pm, "Herbert Rosenau" <os2...@pc-rosenau.de> wrote:
> On Sun, 2 Mar 2008 18:18:16 UTC, Kelsey Bjarnason
>
> <kbjarna...@gmail.com> wrote:
> > [snips]
>
> > On Sat, 01 Mar 2008 19:19:03 +0000, Herbert Rosenau wrote:
>
> > > In contrary to your false assumption there is nothing in the standard
> > > that forbids to give back borrowed memory to the OS and request it from
> > > there again when needed.
>
> > Actually, the wording of the standard forbids it. *If you disagree,
> > please point out any part of the definition of free which allows
> > implementation-defined or unspecified behaviour which would allow free to
> > behave as you describe.
>
> Again, where in the stadard is 'make available to further allocation
> only to the current program in a multiprogram environment' mentioned?
> I can find only 'make available for furhter allocation by anywhom' who
> can get that block' There no requirement that the block has only to
> give out
> - in lower size
> - in bigger size
> - to the same thread
> - to other thread
> - to the same process
> - to other process
> - to a driver
> - never to a driver
> - to the OS for internal use
> - ...
>
> The standard simple lefts unspecified who will, can, may, should (not)
> do the allocation request. As it is unspecified it is left to the
> implementation to define which receivers will able to recive the
> memory. You faild until now to give chapter and verse the standard
> forbids/denys that memory that was given once to a program can no more
> given to another. That proves that you are wrong.
>
>
>
>
>
> > You can't; it's not there. *What is there is a black-and-white guarantee,
> > made by the C standard, about the C standard library, to the C program
> > and C programmer: the memory *is* made available for further allocation.
>
> > You're arguing that the C standard is *not* in fact defining the
> > behaviour of the C standard library, that we're free to add in any random
> > additional crud we feel like, whenever we want, as long as it's not
> > *explicitly* forbidden by the standard.
>
> > So, for example, nothing in the standard *explicitly* forbids the
> > following from printing "Yes!":
>
> > int x = 3;
>
> > if ( ++x == 179 )
> > * *puts( "Yes!" );
>
> > There's nothing in the standard which explicitly forbids this is there? *
> > No, there isn't. *If you don't believe me, feel free to check and quote
> > C&V which forbids this.
>
> You comes with complete nonsens because you fails to give chapter and
> verse where the standard specifies that anything that is not explicity
> allowed is forbidden.
>
> > No, what the standard does is defines the behaviour that *is* supposed to
> > - even guaranteed to - happen. *That *defined* behaviour is what prevents
> > the above printing "Yes!". *Just as the *defined* behaviour is what
> > prevents free returning the memory to the OS; the definition of free
> > *does not allow it* unless the implementation can *guarantee* the memory
> > will be made available to the program again - which, in the general case,
> > it cannot, meaning in the general case it *must* not return the memory to
> > the OS.
>
> Now you comes and says that the stadard allows giving the now freed
> memory away to anywhom who requests it as it does not forbids that
> explicity - in contrast to any you've sayd before.

Here is why I think that Kelsey has a point.
from ISO/IEC 9899:1999 (E), page 312:
"Synopsis
1 #include <stdlib.h>
void free(void *ptr);
Description
2 The free function causes the space pointed to by ptr to be
deallocated, that is, made available for further allocation."

Let's consider what is meant by the phrase "made available for further
allocation"...
If I am reading this document to understand how my program is going to
behave, "made available for further allocation" can only have one
sensible application -- how my program is going to behave. If it
really means "the memory is returned to the operating system for
further use by other programs" then it does not need to be in the
document at all. It may as well say "...that is, the memory may be
eaten by a dragon." because I cannot tell anything about how it
affects my program in the future from the statement.

So, I think if you are reading the document as a compiler writer, then
it can be interpreted as returning the memory to the operating system
for further allocation (I know of at least one compiler that *does*
retain the memory for the C program to use in the future, because
after a call to free() is made with a large block allocated, the
memory footprint for the program does not reduce). If the memory is
not made available to my program again, then it is pointless to
specify what happens to it, from the standpoint of "How will my
program behave?" which is (I suspect) the majority of the reader's of
the document's viewpoint.

I think something along the lines of:
"2 The free function causes the space pointed to by ptr to be
deallocated, that is, made available for further allocation either by
the executing C program or by other tasks requesting memory
resources." would be a better wording. It leaves both retention by
the current program or allocation by other programs as possibilities,
and does not leaving us wondering if the meaning is exclusively
either: "returned to the operating system" or "returned to the
program".

Or something along those lines.
IMO-YMMV.