[Qemu-devel] When it's okay to treat OOM as fatal?

[Markus Armbruster <armbru@redhat.com>]

We sometimes use g_new() & friends, which abort() on OOM, and sometimes
g_try_new() & friends, which can fail, and therefore require error
handling.

HACKING points out the difference, but is mum on when to use what:

    3. Low level memory management

    Use of the malloc/free/realloc/calloc/valloc/memalign/posix_memalign
    APIs is not allowed in the QEMU codebase. Instead of these routines,
    use the GLib memory allocation routines g_malloc/g_malloc0/g_new/
    g_new0/g_realloc/g_free or QEMU's qemu_memalign/qemu_blockalign/qemu_vfree
    APIs.

    Please note that g_malloc will exit on allocation failure, so there
    is no need to test for failure (as you would have to with malloc).
    Calling g_malloc with a zero size is valid and will return NULL.

    Prefer g_new(T, n) instead of g_malloc(sizeof(T) * n) for the following
    reasons:

      a. It catches multiplication overflowing size_t;
      b. It returns T * instead of void *, letting compiler catch more type
         errors.

    Declarations like T *v = g_malloc(sizeof(*v)) are acceptable, though.

    Memory allocated by qemu_memalign or qemu_blockalign must be freed with
    qemu_vfree, since breaking this will cause problems on Win32.

Now, in my personal opinion, handling OOM gracefully is worth the
(commonly considerable) trouble when you're coding for an Apple II or
similar.  Anything that pages commonly becomes unusable long before
allocations fail.  Anything that overcommits will send you a (commonly
lethal) signal instead.  Anything that tries handling OOM gracefully,
and manages to dodge both these bullets somehow, will commonly get it
wrong and crash.

But others are entitled to their opinions as much as I am.  I just want
to know what our rules are, preferably in the form of a patch to
HACKING.