«

On Mon, 19 Nov 2007 22:50:12 +0000, Malcolm McLean wrote:
> "Richard Heathfield" <> wrote in message
>> Unless of course some brain-damaged library designer has arranged that
>> malloc never, ever returns NULL, so that even properly-written
>> applications can't tell whether a request succeeded or not. If ever
>> there was a decision that favoured the mediocre over the competent,
>> that's the one.
>>
> That's me.
> Check out xmalloc(), a malloc that never returnsNULL, on my website.

Your xmalloc aborts (by default) when no memory is available. I believe
Mr. Heathfield was referring to a particular malloc implementation that
returns a non-null pointer even when no memory is available, causing
either that program, or some semi-random other program to crash at some
later time when the memory gets used, without any way for the program to
handle the error.

$)CHarald van D)&k wrote:
> Malcolm McLean wrote:
>> "Richard Heathfield" <> wrote in message
>>
>>> Unless of course some brain-damaged library designer has arranged
>>> that malloc never, ever returns NULL, so that even properly-written
>>> applications can't tell whether a request succeeded or not. If ever
>>> there was a decision that favoured the mediocre over the competent,
>>> that's the one.
>>
>> That's me.
>> Check out xmalloc(), a malloc that never returnsNULL, on my website.
>
> Your xmalloc aborts (by default) when no memory is available. I believe
> Mr. Heathfield was referring to a particular malloc implementation that
> returns a non-null pointer even when no memory is available, causing
> either that program, or some semi-random other program to crash at some
> later time when the memory gets used, without any way for the program to
> handle the error.

I doubt it. He is probably referring to just what Mr. McLean has
apparently done, i.e. automatic program abort. Now the program has
no way of detecting that memory is no longer available, and cannot
take remedial steps.

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



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

??Harald van D??k said:

<snip>

> I believe
> Mr. Heathfield was referring to a particular malloc implementation that
> returns a non-null pointer even when no memory is available [...]

Mr van Dijk believes correctly.

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

CBFalconer said:

> $)CHarald van D)&k wrote:
>> Malcolm McLean wrote:
>>> "Richard Heathfield" <> wrote in message
>>>
>>>> Unless of course some brain-damaged library designer has arranged
>>>> that malloc never, ever returns NULL, so that even properly-written
>>>> applications can't tell whether a request succeeded or not. If ever
>>>> there was a decision that favoured the mediocre over the competent,
>>>> that's the one.
>>>
>>> That's me.
>>> Check out xmalloc(), a malloc that never returnsNULL, on my website.
>>
>> Your xmalloc aborts (by default) when no memory is available. I believe
>> Mr. Heathfield was referring to a particular malloc implementation that
>> returns a non-null pointer even when no memory is available, causing
>> either that program, or some semi-random other program to crash at some
>> later time when the memory gets used, without any way for the program to
>> handle the error.
>
> I doubt it.

You doubt wrong.

> He is probably referring to just what Mr. McLean has
> apparently done, i.e. automatic program abort. Now the program has
> no way of detecting that memory is no longer available, and cannot
> take remedial steps.

No, it is easy to solve the problems caused by Mr McLean's function, by the
simple expedient of not using it.

It's a lot harder to avoid malloc.

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

On Nov 19, 3:34 pm, Evenbit <nbaker2...@charter.net> wrote:
> On Nov 18, 12:46 am, Keith Kanios <ke...@kanios.net> wrote:
>
>
>
> > Ah... theory. Leaves a nice warm feeling, doesn't it?
>
> ... and leads to my trade-mark trait of "going off half-cocked!"

There's nothing to prove around here, only knowledge to gain and
eventually give back.

>
>
> > Three potential solutions to fix your unsound comments.
>
> > 1) Re-read those books.
> > 2) Get more modern/informative books.
> > 3) Try a little practical implementation so you can see why it is so
> > foolish to back such inconsistent theories or potential
> > misunderstandings.
>
> Luckily, just re-reading them was enough to convince me of my error.
> My confusion was due to putting too much emphasis on the fact that
> blocks always contain pages that are assigned to contiguous regions of
> a process' address space. It is true that it is possible to fragment
> (make a mess of) the process' address space, but this should only
> happen due to extremely bad code or via intentional effort on the part
> of the programmer. Even then, I suspect that any "fragmentation wall"
> is purely theoretical because your process would be stopped long
> before it could be hit.
>
> Also, if you write an application that is extremely memory-hungry, you
> need to scrap everything and go back to the flow-charts for an
> entirely different design.
>
> Nathan.

There you go

"Malcolm McLean" <> wrote:

> "Richard Heathfield" <> wrote in message
> >
> > Unless of course some brain-damaged library designer has arranged that
> > malloc never, ever returns NULL, so that even properly-written
> > applications can't tell whether a request succeeded or not. If ever there
> > was a decision that favoured the mediocre over the competent, that's the
> > one.
>
> That's me.

To a tee.

> Check out xmalloc(), a malloc that never returnsNULL, on my website.

A malloc() replacement that never returns a null pointer must eventually
resort to doing something much worse.

Richard

"Richard Bos" <> wrote in message
> "Malcolm McLean" <> wrote:
>
>> Check out xmalloc(), a malloc that never returnsNULL, on my website.
>
> A malloc() replacement that never returns a null pointer must eventually
> resort to doing something much worse.
>
It's good for medium-critical applications.
If you request a small amount of memory then it is unlikely that the user
cannot close down some other application to release it. Alternatively the
callback could release an emergency store. However then it would have to
post a quit message, because of the danger that user might simply continue.

If you request a massive amount of memory that's probably because of a bug
or malicious input, so it is unclear what to do in that situation anyway.

In very critical applications, you will want to recover gracefully from a
memory allocation failure. This adds very substantially to the costs of
writing the code, and is also difficult to test. However if the program must
under no circumstances terminate, this is what you must do. xmalloc()
supposes that termination can be used as a last / first resort, depending on
the program.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

"Malcolm McLean" <> wrote:

> "Richard Bos" <> wrote in message
> > "Malcolm McLean" <> wrote:
> >
> >> Check out xmalloc(), a malloc that never returnsNULL, on my website.
> >
> > A malloc() replacement that never returns a null pointer must eventually
> > resort to doing something much worse.
> >
> It's good for medium-critical applications.
> If you request a small amount of memory then it is unlikely that the user
> cannot close down some other application to release it. Alternatively the
> callback could release an emergency store. However then it would have to
> post a quit message, because of the danger that user might simply continue.
>
> If you request a massive amount of memory that's probably because of a bug
> or malicious input, so it is unclear what to do in that situation anyway.
>
> In very critical applications, you will want to recover gracefully from a
> memory allocation failure. This adds very substantially to the costs of
> writing the code, and is also difficult to test. However if the program must
> under no circumstances terminate, this is what you must do. xmalloc()
> supposes that termination can be used as a last / first resort, depending on
> the program.

Tell me, have you ever pasted a large graphic into a report?

Richard

"Richard Bos" <> wrote in message
> "Malcolm McLean" <> wrote:
>
>> In very critical applications, you will want to recover gracefully from a
>> memory allocation failure. This adds very substantially to the costs of
>> writing the code, and is also difficult to test. However if the program
>> must
>> under no circumstances terminate, this is what you must do. xmalloc()
>> supposes that termination can be used as a last / first resort, depending
>> on
>> the program.
>
> Tell me, have you ever pasted a large graphic into a report?
>
You shouldn't use the xmalloc() handler as part of the "normal" flow control
of the program.
Let's say we are allocating an image of 1 million bytes. At the same time we
allocate a hundred byte string to hold the image name. Let's also say that
the user experiences one allocation failure per day of using the program, on
average.
A simple calculation will show that, assuming 50 working weeks of 5 days
each, he can expect the failure to be in the hundred byte allocation about
once every 40 years. For the vast majority of "lose a day's work" type
critical applications, that sort of failure rate is acceptable. it is much
lower than the chance of a hardware failure in the same time. On the other
hand one failure a day isn't acceptable, so we've got to handle it rather
better. But the failure-handling routines tend to add considerable
complexity to code, and it's hard to test.
The point of xmalloc() is that even if the allocation does fail, we can
choose to give the user a chance to get some more memory. However we don't
have special error-handling recovery code. It's simply not worth coding and
testing - and they tend to be hard to test - custom error handlers for such
rare problems, unless the future of the business is at stake if we have to
crash. It's a misallocation of scare programming resources.

Note that even if the once in forty years problem does come up, we can still
give the user the chance to close down some applications. If he can't get a
hundred bytes from the system, anywhere, it is likely that he'll have to
reboot anyway.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm