Are you sure?

Posted Jun 28, 2011 23:33 UTC (Tue) by brouhaha (subscriber, #1698)
In reply to: Are you sure? by nix
Parent article: Zeuthen: Writing a C library, part 1

You can do the same thing with malloc/realloc/strdup wrappers by having the wrapper log a stack backtrace, e.g., using GNU libc backtrace().

Alternatively, for platforms without backtrace() or equivalent, write your wrappers to accept additional arguments for the message to log for failure. If desired, you could use macros to make that a compile-time conditional, though I personally don't ever turn off any low-overhead debugging code.

Either approach seems far better than littering the source code with explict tests after each allocation. That just makes the code harder to read and maintain.

Are you sure?

Posted Jun 29, 2011 10:59 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)

Your approach (the second one) would have worked, if I could have revamped the entire source base to use it. But it is rare that one gets the opportunity to do that, and malloc() tests at least don't look strange. xmalloc() with a message will make people stop and think when they see it: it's strange and new. malloc() without one and a test: everyone can read that.

Are you sure?

Posted Jun 29, 2011 20:44 UTC (Wed) by brouhaha (subscriber, #1698) [Link] (1 responses)

For a large source base, I definitely wouldn't make a major change throughout, unless it was broken throughout.

I'm not thrilled with the name xmalloc(); I'd probably steal Perl's convention and call it malloc_or_die().

None of these approaches are well-suited to the original problem of doing memory management inside a library. The best practice I know of there is to pass in pointers to allocation/deallocation functions when the library is initialized, and make sure that any failures reported by those functions are handled appropriately. Appropriate means that if the library can't do anything sensible, it at least reports the allocation failure back to the caller.

When I use such a library, I might well pass in a malloc wrapper that prints a stack backtrace and exits.

Are you sure?

Posted Jun 30, 2011 12:53 UTC (Thu) by nix (subscriber, #2304) [Link]

Yes exactly. Generally, library functions which immediately allocate storage will be returning a pointer to that storage: they can return NULL. Library functions which *call* such functions may have more complex work to do, including possibly unwinding partially-completed work. If *this* would require memory allocation, you may need to find a different algorithm, or arrange to do all allocations first (I've done both at various times).

But saying "I won't bother, I'll just abort" is a disservice to your users, no matter *how* hard it is to handle OOM.

Are you sure?

Posted Jun 30, 2011 6:19 UTC (Thu) by cpeterso (guest, #305) [Link]

> Your approach (the second one) would have worked, if I could have revamped the entire source base to use it. But it is rare that one gets the opportunity to do that, and malloc() tests at least don't look strange.

If you're brave, there's always the C preprocessor:

#define malloc(size) my_xmalloc_with_msg(size, __FILE__, __LINE__, __FUNCTION__)

This approach could still be useful if your macro was only #included by a subset of .c files, leaving some object code still calling libc's malloc().