Re: Proposal: g_set_out_of_mem_handler

[Havoc Pennington <hp redhat com>]

On Fri, 3 Dec 1999, Tim Janik wrote:
> 
> well, that can be reduced to
>

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

Yep
 
> since malloc() usually doesn't fail with ENOMEM it's a pretty minor
> portinon of core dumps you'd avoid anyways.
>

not a big deal, given the handler.
 
> i'd rather call this g_try_malloc() to be consistent with other

sounds good.

> 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())?

well g_try_realloc() is functionally distinct from g_try_malloc(), since
you might want to avoid allocating both chunks simultaneously (especially
since these are meant for use with large chunks). Presumably realloc() is
smart enough to extend the original chunk if possible and reduce total
memory use.

_new(), _new0(), etc. are just convenience wrappers so they are not
necessary.

Havoc