«

jacob navia wrote:
> 1:
> It is not possible to check EVERY malloc result within complex software.
>

Pardon me.I haven't programmed for a few years but I was involved in
some fairly complex software development. Why is it not possible to
check every malloc result?

On Tue, 29 Jan 2008 12:47:27 +0100,
jacob navia <> wrote:
> 1:
> It is not possible to check EVERY malloc result within complex software.

Why not?

Martien
--
|
Martien Verbruggen | System Administration is a dirty job, but
| someone said I had to do it.
|

wrote:
> jacob navia wrote:
>
>> 1:
>> It is not possible to check EVERY malloc result within complex
>> software.
>
> Pardon me.I haven't programmed for a few years but I was involved
> in some fairly complex software development. Why is it not
> possible to check every malloc result?

Don't believe everything you find written here.

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

jacob navia wrote:
> 1:
> It is not possible to check EVERY malloc result within complex software.

I disagree. It is possible. You just have to decide you want to sweat
the details bad enough and do the hard work.

Regards,
Stan Milam
--
Life simultaneously, and paradoxically, makes indurate and pliable the soul.

[snips]

On Tue, 29 Jan 2008 10:00:39 -0800, William Ahern wrote:

> But, that's beside the point. If at outset you write your code intending
> to handle recovery, its not difficult at all. I don't remember (and
> granted I can't remember what I wrote when I first began programming in
> C) ever being in a situation where I found it difficult to recover or
> unwind from a path because of a failed malloc call. Of course, I have
> developed a very structured, almost rote method for writing software
> which suits me. But I did so by necessity, because from very early on I
> never accepted the premise that memory failure could or should be
> ignored.

I think that's the key to it. I keep hearing how it's so hard to check
such things, the code is messy, yadda yadda yadda, yet it's not. Why,
then, do some of us do this and find it relatively straightforward, while
some don't?

I suspect it's because we developed habits - design habits - which
incorporate such checking from the outset, while others don't. We, by
sheer habit, write functions such that they are capable of reporting
failure to their callers and, also by sheer habit, write callers which
check for those errors.

If we were to write code where the called function _could_ fail, but the
caller didn't bother to check for it, we would be faced with three
choices:

1) Just accept our code will fail in unpredictable ways
2) Try to go back and find every place such things can fail and bolt on
the error handling code after the fact
3) Do something like xmalloc - if the allocation fails, just abort

I suspect this is exactly what's happening - that some folks are writing
the code *without* the error handling, then going back in to add it on
later. Obviously, this will mean it's nigh-on impossible to ensure, in a
complex application, that every case is checked. Obviously, it's going
to make things ugly. Obviously, it's going to be a whole heck of a lot
of work.

I don't know that this is what they're doing, but it sounds like it. It
would explain why they think something like xmalloc makes sense, why they
think that "checking every allocation" is so hard to ensure.

It really is just a matter of design, but even simpler, just a matter of
habit. If you're writing code which opens a file or allocates memory, or
some similar operation which can fail in a manner which you can both
detect and deal with, add the code to check it. Now.

It's a habit one can develop, and once it becomes habit, it is very
little effort indeed to ensure you do, in fact, check such things - each
and every time.

On Tue, 29 Jan 2008 12:47:27 +0100, jacob navia wrote:

> 1:
> It is not possible to check EVERY malloc result within complex software.

I already asked why once, but I'll ask again - WHY is it not possible?

It's actually very simple. When I write code which calls malloc - that
is, *immediately after writing the call to malloc* - the very next thing
I do is write the code which checks whether it failed.

ptr = malloc(x);
if ( ! ptr ) { handle }

It's a simple habit. If you develop the habit, it's not merely possible,
but trivial.

Nor is it limited to malloc:

MyWindow *win = createWindow();
if ( ! win ) { handle }

Do I know whether createWindow calls malloc? No. Nor do I care. What I
care about is that it can fail, and on failure, returns NULL. Nor is
this limited to allocations:

int sock = socket(...);
if ( sock == -1 ) { handle }

c = fgetc(fp);
if ( c == EOF ) { handle }

Why is it more difficult to check for allocation failures than to check
that you got a legitimate (non-EOF) character from a file, or a
legitimate socket handle, or any other case where the value returned may
be an indicator of a failure state?

On Wed, 30 Jan 2008 10:19:21 -0500, Kenneth Brody wrote:

> Kelsey Bjarnason wrote:
>>
>> [snips]
>>
>> On Tue, 29 Jan 2008 10:00:39 -0800, William Ahern wrote:
>>
>> > But, that's beside the point. If at outset you write your code
>> > intending to handle recovery, its not difficult at all. I don't
>> > remember (and granted I can't remember what I wrote when I first
>> > began programming in C) ever being in a situation where I found it
>> > difficult to recover or unwind from a path because of a failed malloc
>> > call. Of course, I have developed a very structured, almost rote
>> > method for writing software which suits me. But I did so by
>> > necessity, because from very early on I never accepted the premise
>> > that memory failure could or should be ignored.
>>
>> I think that's the key to it. I keep hearing how it's so hard to check
>> such things, the code is messy, yadda yadda yadda, yet it's not. Why,
>> then, do some of us do this and find it relatively straightforward,
>> while some don't?
>
> It's also possible that a failed malloc() is not fatal.

Kinda the point to the whole discussion. The tools - xmalloc et al -
treat failure as fatal, when it often isn't, and even if it is, *I* - the
developer - want to decide what to do about it.

> point, it simply uses whatever memory it allocated. A failed malloc()
> simply means "don't allocate any more chunks", and is handled no
> differently than "I have already allocated the maximum number of chunks
> I was told to allow".

Bingo. It is *not* a situation where the only possible response is to
scream and die.

Kelsey Bjarnason wrote:
>
> [snips]
>
> On Tue, 29 Jan 2008 10:00:39 -0800, William Ahern wrote:
>
> > But, that's beside the point. If at outset you write your code intending
> > to handle recovery, its not difficult at all. I don't remember (and
> > granted I can't remember what I wrote when I first began programming in
> > C) ever being in a situation where I found it difficult to recover or
> > unwind from a path because of a failed malloc call. Of course, I have
> > developed a very structured, almost rote method for writing software
> > which suits me. But I did so by necessity, because from very early on I
> > never accepted the premise that memory failure could or should be
> > ignored.
>
> I think that's the key to it. I keep hearing how it's so hard to check
> such things, the code is messy, yadda yadda yadda, yet it's not. Why,
> then, do some of us do this and find it relatively straightforward, while
> some don't?

It's also possible that a failed malloc() is not fatal.

I have a function which builds an index of records in a database.
The sort routine allocates memory in chunks. As long as the first
malloc() succeeds, it is irrelevent whether later mallocs() succeed
or not. As it wants more memory, it malloc()s another chunk for
its buffers, until either it has all the memory it needs to hold
all of the sort keys, hits a configurable maximum number of chunks,
or malloc() fails. At that point, it simply uses whatever memory
it allocated. A failed malloc() simply means "don't allocate any
more chunks", and is handled no differently than "I have already
allocated the maximum number of chunks I was told to allow".

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <private.php?do=newpm&u=>

[snips]

On Wed, 30 Jan 2008 16:44:51 +0000, dj3vande wrote:

> That said, I'm currently writing a code generator that uses xmalloc-
> style wrappers. But that's a design decision ("I won't have anything to
> do but abort anyways, so I might as well do it at the bottom instead of
> at the top"), not ignorance of the issues ("Error recovery is Hard, so I
> won't bother").

Right. If there absolutely is nothing else you can do, you have to
abort. Sometimes - rarely, but sometimes - that is, in fact, the only
sensible _first_ thing to do. It should not be the first thing as a
matter of policy or habit, though; if anything it should be the last.

As you describe it - "I won't have anything to do but abort anyways" -
there's little point in your trying, as you wouldn't buy anything by it;
it makes sense in such a case. As a habit, policy or general design
decision? No.

William Ahern wrote:
>
> Serve Laurijssen <> wrote:
>
> > Think he meant it's not possible to HANDLE every malloc failure. Indeed its
> > pretty easy putting an if in there, but not so easy to actually gracefully
> > handle it.
>
> But, that's beside the point. If at outset you write your code intending to
> handle recovery, its not difficult at all.

Sometimes yes and sometimes no, depending on the work being done.
Allocation failure in one application I developed required
(automagical) powering up another network node to run another
instance of the application, and moving a portion of the
unexpectedly large body of information to the new node without
significantly impacting throughput. The recovery process was
complicated by the need to implement the reverse when loading
shrank.

/Sometimes/ it's not difficult.

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto