Re: xmalloc string functions

On Jan 28, 9:27 am, Kelsey Bjarnason <kbjarna...@xxxxxxxxx> wrote:
[snips]

On Mon, 28 Jan 2008 04:17:54 +0000, Yevgen Muntyan wrote:
No idea, ask the developers of that buggy application. Failed fopen() is
not an exceptional condition. Failed malloc() is. Or we are using
different vocabularies.

Apparently so. To me, they are both error conditions, to be handled
appropriately - by the caller. Neither is exceptional.

To my mind, there's no difference in effort required to handle a NULL
return from fopen(), than a NULL return from malloc(). Maybe more
typing.
Then you are just really good. Because it's enormously more typing.

if ( ( file = fopen(...) ) == NULL ) {}
if ( ( ptr = malloc(...) ) == NULL ) {}

Yeah, enormously more, indeed.

I love how everybody pushes such toy code. You forgot
the part inside {}, you know.


And
more than that, it's more design questions too: "what do I do in this
situation, which I can't even possibly test?"

Can't test? Why can't you test an allocation failure? I do it all the
time. It's pretty trivial, actually, if you're using a language which
includes constructs such as if ( condition ) action. You know, like,
say, C.

Not test as in 'if(something)'. Test as in "run the program and
see what happens when that allocation fails".


All this apart from real
problems you have to solve. Yes, *real*. No, g_malloc() aborting an
application is not a real problem. Not for a regular desktop
application.

Except that at least one person *here*, in a comparatively small
community, has reported application crashes *precisely* due to this.

He did, didn't he.


I wish I knew where this notion of "Hey, it's just an application, feel
free to kill it because it's 3:00, or the sky is blue, or whatever other
random event has occurred" has come from. I've been cranking apps for
most of 30 years now, and I have *never* found it acceptable for an
application to simply terminate, unless there is absolutely no other
possible option.

This is
just a resource acquisition issue, and even if you had infinite memory
it's a pattern you still have to deal with.

Except you don't open files twenty times in a row in every function in
your application. Memory is quite a different kind of resource.
Different in how you use it, you know.

Different how? Files or memory, each needs to be requested before use,
each can fail on request, each needs to have the request failure dealt
with. If the request is successful, the resource is used then disposed
of by appropriate means.

In terms *relevant to the topic*, there is no difference at all.
Request, cope with possible request failure, use, dispose.

Yeah. Stack space is also such a resource. Do you always use whatever
your implementation provides to cope with stack allocation failure?
Just curious.


Granted, I've not done much work with X11 applications, or GUI
applications in general. But, I fail to understand how a caveat wrt to
X11 justifies--absent other reasons--exiting when a string cannot be
allocated.
So you click Save button then click Close. The application failed to
process Save click because it failed to allocate memory for the event
structure to put into the event queue, but then it successfully handled
Close because at the same time yet another document was closed and some
memory returned to the malloc pool.

That strikes me as a design flaw in the application. If the user
requested "save and close" and the save failed, what the hell are you
doing processing the close, instead of dealing with the error?

The application has no idea that user clicked "Save" in this case.
So it didn't fail to save. The very event was dropped and forgotten.
Of course it's a made up example, no need to talk about design here.
A more realistic one is:

void the_toolkit_event_function (Event *event)
{
event_queue = g_list_prepend (event_queue, copy (event));
}

What do you do there if g_list_prepend fails because it failed
to allocate space for the list link? You just can't drop the
event, because that could lead to funny things like ignoring
user requests (or worse, X is funny like that).

This would be particularly bad since the failure to save was *not*
because a file couldn't be written to, but because a menu event couldn't
be put in a message queue. If you must process the close, at least have
the decency to save the data, possibly in a scratch file which can be
recovered next time around.

Yes, certainly, at some point the options run out. If you can't allocate
space for a message on the queue, you probably also can't allocate
resources for a warning dialog. If you can't create a scratch file *and*
you can't allocate resources for the warning, there may be little you can
do but abort.

That, however, does not excuse the whole notion of "Hey, first thing we
tried failed, so let's just abort."

Nobody said this, you can do stuff on malloc() failure.
But even without that, this whole notion is very useful
in applications where it's acceptable. I won't care much
if my mp3 player crashes when my X display is frozen anyway.
You can handle malloc() failures how much you want there,
and it will be pointless.


All allocations are checked. It's what you do when they fail is
different. If malloc(12) failed, then you are screwed because all your
code wants memory.

No, you're not screwed. You have a possible failure condition to deal
with, one which might be an expected condition, one which might not be,
and in either case, there are many possible resolutions to the problem.

Indeed. And you make these decisions thousands times in your code,
and you test every one, and every one is exactly the best and right.
And there is a peace in the world, and so on.


No memory => application isn't working.

Or application isn't working optimally. Or _this part_ of the
application isn't working _now_, so try again in five minutes. Or...

.... is especially good when you are writing code. I believe the
first choice is better.

Yevgen
.