Suppose I have a function that allocates memory for the caller:
int func(void **mem1, void **mem2) {
*mem1 = malloc(SIZE);
if (!*mem1) return 1;
*mem2 = malloc(SIZE);
if (!*mem2) {
/* ... */
return 1;
}
return 0;
}
I'd like to hear your feedback on the best way to free() the allocated memory in case the second malloc() fails. You can imagine a more elaborate situation with more error exit points and more allocated memory.
I know people are loathe to use them, but this is the perfect situation for a
goto
in C.This is a bit controversial, but I think the
goto
approach used in Linux kernel actually works pretty well in this situation:Personally; I have a resource tracking library (basically a balanced binary tree) and I have wrappers for all allocation functions.
Resources (such as memory, sockets, file descriptors, semaphores, etc - anything you allocate and deallocate) can belong to a set.
I also have an error handling library, whereby the first argument to each function is an error set and if something goes wrong, the function experiencing an error submits an error into the error set.
If an error set contains an error, no functions execute. (I have a macro at the top of every function which causes it to return).
So multiple mallocs look like this;
There is no need to check the return value, because if an error occurs, no following functions will execute, e.g. the following mallocs never occur.
So, when the time comes for me to deallocate resources (say at the end of a function, where all the resources used internally by that function have been placed into a set), I deallocate the set. It's just one function call.
I don't need to specifically check for errors - there are no if()s in my code checking return values, which makes it maintainable; I find the profliferation of in-line error check destroys readability and so maintainability. I just have a nice plain list of function calls.
It's art, man :-)
If the above goto statements horrify you for some reason, you can always do something like this:
I use this method pretty regularly, but only when it's very clear what's going on.
My own inclination is to create a variable argument function that frees all non-NULL pointers. Then the caller can handle the error case:
This is where a goto is appropriate, in my opinion. I used to follow the anti-goto dogma, but I changed that when it was pointed out to me that do { ... } while (0); compiles to the same code, but isn't as easy to read. Just follow the some basic rules, like not going backwards with them, keeping them to a minimum, only using them for error conditions, etc...