Hi,

Erik Faye-Lund wrote:

> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -367,7 +367,7 @@ static void squash_message(struct commit *commit, struct 
> commit_list *remotehead
>                       sha1_to_hex(commit->object.sha1));
>               pretty_print_commit(&ctx, commit, &out);
>       }
> -     if (write(fd, out.buf, out.len) < 0)
> +     if (xwrite(fd, out.buf, out.len) < 0)
>               die_errno(_("Writing SQUASH_MSG"));

Shouldn't this use write_in_full() to avoid a silently truncated result? (*)

[...]
> --- a/streaming.c
> +++ b/streaming.c
> @@ -538,7 +538,7 @@ int stream_blob_to_fd(int fd, unsigned const char *sha1, 
> struct stream_filter *f
>                       goto close_and_exit;
>       }
>       if (kept && (lseek(fd, kept - 1, SEEK_CUR) == (off_t) -1 ||
> -                  write(fd, "", 1) != 1))
> +                  xwrite(fd, "", 1) != 1))

Yeah, if we get EINTR then it's worth retrying.

[...]
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -1129,9 +1129,8 @@ static int udt_do_write(struct unidirectional_transfer 
> *t)
>               return 0;       /* Nothing to write. */
>  
>       transfer_debug("%s is writable", t->dest_name);
> -     bytes = write(t->dest, t->buf, t->bufuse);
> -     if (bytes < 0 && errno != EWOULDBLOCK && errno != EAGAIN &&
> -             errno != EINTR) {
> +     bytes = xwrite(t->dest, t->buf, t->bufuse);
> +     if (bytes < 0 && errno != EWOULDBLOCK) {

Here the write is limited by BUFFERSIZE, and returning to the outer
loop to try another read when the write returns EAGAIN, like the
original code does, seems philosophically like the right thing to do.

Luckily we don't use O_NONBLOCK anywhere, so the change shouldn't
matter in practice.  So although it doesn't do any good, using xwrite
here for consistency should be fine.

So my only worry is the (*) above.  With that change,
Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to