Re: glib CVS ?

[DINH Viet Hoa <dinh viet hoa free fr>]

On Mon, 26 Nov 2001 12:34:07 +0100 (CET)
"Tim Janik" <timj gtk org> wrote:

> > > > GString should be changed in order to use these
> > > > g_try_realloc/g_try_malloc in order to recover from failed memory
> > > > allocation, don't you think so ?
> > > 
> > > nope, GString's API doesn't have any provisions for reporting errors
> > > ala "don't use me i couldn't allocate enough memory".

it seems that GString API can report such errors, for example
g_string_append return a GString *, we can return NULL on errors,
and it seems that almost all functions in API concerning memory
reallocation can return error notification this way.

> > Couldn't it be added (I can do it and submit a patch)
> 
> nope, we're in API freeze already.

there would not be any API changed.

> > > a good example of where g_try_malloc() is apropriate is the pixbuf
> > > loading code, where out-of-mem is just another error condition
> > > besides various other reasons for why an image couldn't get loaded,
> > > and the allocation failing my very well be due to a broken image
> > > file (say it told you to allocater space for 65535*65535 pixels).
> > 
> > The fact is that I am developing a library where I use
> > GStrings and I can't exit the main program in case the memory
> > allocation could not be done, and GString I will be manipulating
> > can be enough large to induce out-of-memory errors.
> > The program that will use this library should not exit on
> > failure.
> 
> if out-of-mem is really a valid situation for your string manipulations
> (usually things are messed up anyways if strings are allocated bigger
> than memory available) you might want to use your own string handling
> code.
> note that GString can be quite inefficient if you use really huge strings,
> e.g. when prepending a substring or a character to a 10MB string, you'll
> effectively cause a 10MB memove().
> in such situations it might be better to do things like:
> 
> GSList *slist, *word_list = NULL;
> guint l = 0;
> gchar *p, *s;
> /* prepend words */
> for (i = 0; i < n_words; i++)
>   word_list = g_slist_prepend (word_list, words[i]);
> /* finally, fold words into a real string */
> for (slist = word_list; slist; slist = slist->next)
>   l += strlen (slist->data);
> s = p = g_try_malloc (l + 1);
> if (!p)
>   die ("not enough memory for string hackery");
> for (slist = word_list; slist; slist = slist->next)
>   {
>     strcpy (p, slist->data);
>     p += strlen (slist->data);
>   }
> g_slist_free (word_list);
> g_print ("long string: %s\n", s);

what would be interesting for me is to use an object
that already exists.

> > I really think that a library should not make a decision for
> > the program that uses it do fail and to exit.
> 
> if we didn't do this, we'd have to pass up malloc errors through
> virtually every public function, quite impossible if you think of
> the usual call stack depth of the average gtk program.
> considering that 99% of failing malloc()s are due to passing invalid args
> (such as: 4 - 5) or the system being brought to a halt anyways, and that,
> even if we handled g_malloc() failing more gracefully, things would usually
> still blow up in other libs (e.g. xlib), checking NULL malloc() returns would
> basically screw our API at little to no practical benefit.

As it was said, this could also be an allocation of a memory bloc larger
than the memory.
I hoped that glib did not apply only to gtk (and this is my case).
I use it only for data structures that I wouldn't have to implement.

> since most programs would simply exit upon malloc()==NULL anyways - after
> all, you can't pop up a dialog or somesuch in a situation like this - doing
> the exit right away in g_malloc() is good enough for most apps.
> (and those for which this falls short can still hook up their own memory
> vtable).

For example, before the program would failed, it could be interesting
for it to try to save any useful data.

-- 
DINH Viêt Hoà