On Thu, Feb 22, 2018 at 08:29:25PM +0100, René Scharfe wrote:
> Reduce code duplication by factoring out a function that reads an entire
> file into a strbuf, or reports errors on stderr if something goes wrong.
>
> Signed-off-by: Rene Scharfe <l....@web.de>
> ---
> The difference to using strbuf_read_file() is more detailed error
> messages for open(2) failures. But I don't know if we need them -- or
> under which circumstances reading todo files could fail anyway. When
> doing multiple rebases in parallel perhaps?
I'm fine with this patch, but FWIW I think reporting the result of
strbuf_read_file with error_errno() would actually be an improvement.
The errno values are generally sufficient to tell if the problem was in
opening or reading, and then we'd get more information in the case of a
failed read() call.
Thought note...
> diff --git a/sequencer.c b/sequencer.c
> index e9baaf59bd..e34334f0ef 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -1869,22 +1869,31 @@ static int count_commands(struct todo_list *todo_list)
> return count;
> }
>
> +static ssize_t strbuf_read_file_or_whine(struct strbuf *sb, const char *path)
> +{
> + int fd;
> + ssize_t len;
> +
> + fd = open(path, O_RDONLY);
> + if (fd < 0)
> + return error_errno(_("could not open '%s'"), path);
> + len = strbuf_read(sb, fd, 0);
> + close(fd);
> + if (len < 0)
> + return error(_("could not read '%s'."), path);
> + return len;
> +}
If we were to use error_errno() in the second conditional here, we
should take care not to clobber errno during the close(). I think
strbuf_read_file() actually has the same problem, which might be worth
fixing.
-Peff
