| |||||||||||||
Are you sure?Are you sure?Posted Jun 29, 2011 20:44 UTC (Wed) by brouhaha (guest, #1698)In reply to: Are you sure? by nix Parent article: Zeuthen: Writing a C library, part 1
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.
(Log in to post comments)
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.
|
|||||||||||||