Re: xmalloc string functions

On Jan 29, 9:19 am, Nick Keighley <nick_keighley_nos...@xxxxxxxxxxx>
wrote:
On 29 Jan, 09:23, ymunt...@xxxxxxxxx wrote:

On Jan 29, 2:56 am, Nick Keighley <nick_keighley_nos...@xxxxxxxxxxx>
wrote:
On 29 Jan, 08:25, ymunt...@xxxxxxxxx wrote:
On Jan 28, 11:40 am, Kelsey Bjarnason <kbjarna...@xxxxxxxxx> wrote:
On Mon, 28 Jan 2008 15:30:50 -0800, ymuntyan wrote:

<snip>

So, you work with a list, and you append an element to it. Now you do
list = g_list_append(list, something); with malloc error handling you'll
have to test whether list_append() succeeded.

does g_list_append() allocate memory?

Yes. It got to put the data somewhere.

in a preallocated piece of memory maybe?

if ((x = malloc(27)) == 0)
{
save_stuff();
exit(FAILURE);
}

list_append(x);



That depends entirely on how your list functions work. As a simple
example:

/* NODE and LIST are actually the same thing, just written differently
for clarity's sake */
void list_append( LIST *list, NODE *new )
{
NODE *node = list;

/* Find end of list */
while( node->next != NULL )
node = node->next;

/* Add item to end of list */
node->next = new;
new->next = NULL;

}

Sorry, what, exactly, did I need to check here with malloc error
handling? What's that you say, nothing at all, since there _is_ no
malloc involved in adding a node to the list? Ah, yes. Of course, we
need to allocate the node itself:

NODE *node;
LIST *list;

...

node = malloc( sizeof( *node ) );
if ( node == NULL )
{
blah}

else
{
list_append( list, node );
blah

}

Golly, how unbearably painful.

Oh yes. Easy. How many lines of code is that?

very few

You mean nice versus one is very few? OK.

nine? and some of those are brackets

<snip>



That is, lines of untested code (no, I won't buy the
tales that you will test it. You won't)

it seems you're assumptions about his development methodology

I can test it relatively easily. For example, I can use a malloc
wrapper which allows me to force a return of a null pointer when I want
during testing. Or I can use the debugger to put a breakpoint in and
change the pointer value to null at the point I want to trigger the
failure.

There are about five bazillion allocations, debugger won't do.

and the wrapper?

And a code parser which will find all malloc() calls,
and then a script generator which will generate all
possible code paths to make debugger test those
places. I'd be glad to have such a tool, certainly.

Random
malloc() failures will do as a nice stress test, yes. But you still
won't be able to test it properly. At least not that piece of code where
it will segfault when user runs it

Huh? A segfault is a result, generally, of one of two things: a runaway
pointer, or an allocation failure - you know, the very thing we're
suggesting you actually design your code to test for.

I'm saying that you got so many possible segfault places
that you won't test the one where it will actually segfault.

there won't be *any* segfault places. You ALWAYS test the return from
malloc().

Except where you got a bug. In the place you won't
test.

sorry, you must have missed "You ALWAYS test the return from malloc()"

You missed the meaning of "test".


(here I assume that user will be able
to see it, perhaps on windows). A better thing to do is to test malloc()
failure in one place, and possibly do what you can do there, and abort.

Really? Okay, fine. I've got allocated data buffers *with live data* in
793 different places in the code. The only way your "one place" is going
to be able to "do what you can there" and save the data is if every
single piece of data in the entire program is a freaking *global*, which
is *not* gonna happen.

Now, if I don't use this half-baked notion of "allocate or die", I can
report the failure to the caller, and then to its caller, and so on and
so forth, with each level doing whatever is appropriate for the data it
has in its care, *none* of which your method has *any* ability to do.

But hey, it's not like data matters, right? Who cares, data's worthless,
just crash the app.

Okay, okay. After we crashed the application and lost user data,

no no no! The point is you do something with the user data
*before* you terminate the application.

So do it. You *can*. Glib doesn't do anything but abort()
by default, naturally, since it can't do anything else.
If you are fine with this, do nothing. If not, write code
which will save the user data.

no this baffles me. If aborting in the malloc() wrapper
isn't the correct option you don't use it...

so...

no I'm still baffled. Why not follow a policy of try and allocate
memory, if it fails take some application specific recovery action?
Only the application can know what to do.

I don't know why not. You can do that.


And man, I didn't say we should lose the user data!

but you have no choice if malloc crashes!

malloc doesn't crash.

Not necessarily. For example, if you have done your job correctly the
*recovery* code already has the memory it needs allocated, so that can
run successfully.

Recovery code will be able to run successfully, so what?

"So what" is that my data wasn't hooped by your brain-dead strategy of
simply aborting on error, that's what. I know you don't think users'
data actually *means* anything, but I can assure you, the *user* thinks
it does.

Sorry, I didn't say lose data. I said you can't continue working
as nothing happened after that. "Recovery code will be able to run
successfully", right. Now read what you snipped, and *then* argue

"recovery" includes saving data and terminating.

So do it? Who said you shouldn't it? You can save data
and terminate. But you ought to terminate, with saving
or not, if you use glib.

what? glib only crashes sometimes?

It rarely crashes, indeed. What are you talking about?

you don't *have* to terminate. You could free some memory.
Or abort some operation. On large long running systems
you don't die just because the user can't display the current
alarm list

So you write the application in a different way. Gtk
toolkit is not for such an application (not for the
application which leaks so much that it runs out of
memory on the long run).


That's it. But I am told that
an application can do more. No it can't.

sometimes it can.

Sometimes yes. Who objects?


If the main loop
can't push an event onto the event queue, then you're
screwed.

yes, that's a bit extreme. But if it's comoing from an external
source you could discard it and wait for the repeat.

There won't be repeat.

No "application performs worse" or "some parts
are not working".

I think you are mistaken.

(Note, it is not about all applications,
don't talk about failsafe mp3 players or about webservers,
those simply shouldn't use glib)

so what class of application should? Games? Mobile radio Systems?
Database servers?

Desktop applications.

Yevgen

.

Relevant Pages

  • Re: xmalloc string functions
    ... If these were the only choices (crashing applications or a frozen ... trying to malloc some rediculously large amount of memory - e.g. in the ... because their malloc wrapper decided to exit. ... Exiting on malloc failure makes sense for a utility like sort. ...
    (comp.lang.c)
  • Re: xmalloc string functions
    ... Failed malloc() is. ... Why can't you test an allocation failure? ... each can fail on request, each needs to have the request failure dealt ... process Save click because it failed to allocate memory for the event ...
    (comp.lang.c)
  • Re: xmalloc string functions
    ... than a NULL return from malloc(). ... pointer value to null at the point I want to trigger the failure. ... I've also had VMWare report out-of-resource at times when the only resource that was tight was memory, and again it gave me the chance to recover the situation which saved me significant work because I had two VMs running and the state between them was important and took time setting up. ... allocations without reference to other circumstances (number of ...
    (comp.lang.c)
  • Re: Review: My C FAQ Page
    ... the definition of memory leak is good but the information on ... this is not the most efficient way to allocate the 2-d array. ... You have ROW+1 calls to malloc. ... Allocate ROW pointers. ...
    (comp.lang.c)
  • Re: xmalloc string functions
    ... of mallocwhen you are trying to allocate a structure ... caller that fact like I do when malloc() fails to delever me the ... amount of memory I ask it for. ... doesn't have memory to draw stuff it draws. ...
    (comp.lang.c)