Alex Riesen wrote:
> 2009/6/14 Jim Meyering <jim@xxxxxxxxxxxx>:
>> @@ -231,7 +231,7 @@ static int read_merge_config(const char *var, const char *value, void *cb)
>>
>> if (!strcmp(var, "merge.default")) {
>> if (value)
>> - default_ll_merge = strdup(value);
>> + default_ll_merge = xstrdup(value);
>
> read_merge_config has a failure mode (where it returns -1), why not use it?
I didn't even consider it, because it would be inconsistent with
the other heap-allocation functions used there (xcalloc, xmemdupz).
However, now that I do, it looks like that would mean adding four times
the same code (including conditionals and code to generate a diagnostic via
a call to error -- or a goto). Why bother, when all of that is already
encapsulated in xmalloc?
Maybe because you want to be able to continue after an allocation failure?
If a small strdup allocation fails, odds are good that the code won't
be able to do anything useful, so when not in library code, cleanest is
simply to exit.
In addition, if you insist on using strdup, you'll probably want to
be consistent and use calloc and memdupz, too. Adding all of the code
required to recover from those failures and to avoid leaks would be messy.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html