@@ -139,12 +139,10 @@ void display_throughput(struct progress *progress, uint64_t total)
now_ns = getnanotime();
if (!tp) {
- progress->throughput = tp = calloc(1, sizeof(*tp));
- if (tp) {
- tp->prev_total = tp->curr_total = total;
- tp->prev_ns = now_ns;
- strbuf_init(&tp->display, 0);
- }
+ progress->throughput = tp = xcalloc(1, sizeof(*tp));
+ tp->prev_total = tp->curr_total = total;
+ tp->prev_ns = now_ns;
+ strbuf_init(&tp->display, 0);
return;
}
tp->curr_total = total;
@@ -196,13 +194,7 @@ int display_progress(struct progress *progress, uint64_t n)
static struct progress *start_progress_delay(const char *title, uint64_t total,
unsigned delay)
{
- struct progress *progress = malloc(sizeof(*progress));
- if (!progress) {
- /* unlikely, but here's a good fallback */
- fprintf(stderr, "%s...\n", title);
- fflush(stderr);
- return NULL;
- }
+ struct progress *progress = xmalloc(sizeof(*progress));
progress->title = title;
progress->total = total;
progress->last_value = -1;
Since the early days of Git, the progress code allocates its struct with a bare malloc(), not xmalloc(). If the allocation fails, we just avoid showing progress at all. While perhaps a noble goal not to fail the whole operation because of optional progress, in practice: 1. Any failure to allocate a few dozen bytes here means critical path allocations are likely to fail, too. 2. These days we use a strbuf for throughput progress (and there's a patch under discussion to do the same for non-throughput cases, too). And that uses xmalloc() under the hood, which means we'd still die on some allocation failures. Let's switch to xmalloc(). That makes us consistent with the rest of Git and makes it easier to audit for other (less careful) bare mallocs. Signed-off-by: Jeff King <peff@peff.net> --- This one is obviously less urgent than the others in that it doesn't trigger a segfault. So this is purely cleanup. progress.c | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-)