Re: Proposal: g_set_out_of_mem_handler

[Tim Janik <timj gtk org>]

On Fri, 3 Dec 1999, Havoc Pennington wrote:

> So:
>  - allow setting a "try again" function with signature identical to 
>    malloc/realloc

well, that can be reduced to

typedef gpointer (*GReallocFallback) (gpointer mem,
                                      gulong   n_bytes);
void g_realloc_set_fallback (GReallocFallback fallback_func);

with mem=NULL for malloc() fallback (and some realloc()s).

>  - allow replacing the default error handler with some other action,
>    like a custom message or some other kind of cleanup; people
>    could even do a fork() and exec a gnome_segv type of dialog
>    probably

that can be done from the realloc fallback_func if it failed again, no need
to have yet another handler from glib there.

>  - change the default handler to exit(1) instead of abort()

i don't think this is actually a good idea, we currently use g_error()
to abort failing g_malloc()s which is the standard glib error handler
and cares about putting the message somewhere, so programs that reroute
stderr and/or stdout can still log stuff to a file.
apart from that, g_malloc() can fail for allocations like ~(int)0
which may be caused by int wraparounds or similar bugs in a program,
in such cases you want a coredump or backtrace.
since malloc() usually doesn't fail with ENOMEM it's a pretty minor
portinon of core dumps you'd avoid anyways.

>  - add g_unchecked_malloc(), g_unchecked_realloc()

i'd rather call this g_try_malloc() to be consistent with other
API calls in glib, e.g. g_quark_try_string().
also, do we really need a g_try_realloc() variant there (or
corresponding try_malloc0() try_new(), try_new0())?
the rare cases where you allocate a memory region that huge that
you better check whether you'd get it, should be handled fine by
plain g_try_malloc().

> 
> that's really simple and trivial and solves most of the problem...
> 
> Havoc
> 

---
ciaoTJ