On Sun, Apr 24, 2016 at 9:34 AM, Christian Couder
<christian.couder@xxxxxxxxx> wrote:
> Signed-off-by: Christian Couder <chriscool@xxxxxxxxxxxxx>
> ---
> diff --git a/builtin/apply.c b/builtin/apply.c
> @@ -4562,12 +4562,12 @@ static int apply_all_patches(struct apply_state *state,
>
> fd = open(arg, O_RDONLY);
> if (fd < 0)
> - die_errno(_("can't open patch '%s'"), arg);
> + return error(_("can't open patch '%s': %s"), arg, strerror(errno));
> read_stdin = 0;
> set_default_whitespace_mode(state);
> res = apply_patch(state, fd, arg, options);
> if (res < 0)
> - exit(1);
> + return -1;
This leaks 'fd', doesn't it?
> errs |= res;
> close(fd);
> }
> @@ -4590,10 +4590,10 @@ static int apply_all_patches(struct apply_state *state,
> squelched);
> }
> if (state->ws_error_action == die_on_ws_error)
> - die(Q_("%d line adds whitespace errors.",
> - "%d lines add whitespace errors.",
> - state->whitespace_error),
> - state->whitespace_error);
> + return error(Q_("%d line adds whitespace errors.",
> + "%d lines add whitespace errors.",
> + state->whitespace_error),
> + state->whitespace_error);
How does this new 'return' relate to the logic below which updates the
index? Does the index need to be updated here now too?
> if (state->applied_after_fixing_ws && state->apply)
> warning("%d line%s applied after"
> " fixing whitespace errors.",
> @@ -4608,7 +4608,7 @@ static int apply_all_patches(struct apply_state *state,
>
> if (state->update_index) {
> if (write_locked_index(&the_index, state->lock_file, COMMIT_LOCK))
> - die(_("Unable to write new index file"));
> + return error(_("Unable to write new index file"));
> }
>
> return !!errs;
> @@ -4698,5 +4698,8 @@ int cmd_apply(int argc, const char **argv, const char *prefix)
> if (check_apply_state(&state, force_apply))
> exit(1);
>
> - return apply_all_patches(&state, argc, argv, options);
> + if (apply_all_patches(&state, argc, argv, options))
> + exit(1);
> +
> + return 0;
> }
--
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