From: Sebastian Schuberth <sschuberth@gmail.com>
To: Johannes Sixt <j.sixt@viscovery.net>
Cc: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>,
git@vger.kernel.org, msysgit@googlegroups.com,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH] Fix checkout of large files to network shares under Windows XP
Date: Tue, 20 Apr 2010 16:21:36 +0200 [thread overview]
Message-ID: <i2kbdca99241004200721l7cbd0052oa6921533f7efb8a4@mail.gmail.com> (raw)
In-Reply-To: <4BCDA49C.4090405@viscovery.net>
On Tue, Apr 20, 2010 at 14:57, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 4/20/2010 14:42, schrieb Sebastian Schuberth:
>> On Mon, Apr 19, 2010 at 22:43, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>>> Shouldn't the loop be left in the successful case, too? write(2) is
>>> allowed to write less than requested, so the caller already needs to
>>> deal with that case anyway.
>>
>> I prefer to make the wrapper as transparent as possible. If a direct
>> call to write would not write less than requested, the wrapper should
>> not either.
>
> Sure, but René meant the opposite case: When fewer bytes than requested
> were written, then you shouldn't retry to write more! That is, you should
> exit the loop when write(fd, buf, n) does not return n.
I see what you mean, but I do not fully agree. Who guarantees that (on
some obscure OS) a following call to write(fd, buf, n) will not return
n again, maybe because write() temporarily decided to write fewer
bytes than requested to make the next write() call do aligned writes
to something? That case then is probably already handled in the caller
to write(), but at least my code is not wrong in that respect.
> I still find your code unnecessarily hard to read. In particular, you
> should extract the non-problematic case out of the loop. If you followed
> my suggestion elsewhere in the thread, you wouldn't have to write any
> conditionals that 'break' out of a loop.
I didn't follow your suggestion on purpose because I experimented with
it and I found *yours* to be hard to read. It has three calls to
write() and more places where errors need to be checked. As I do not
have the will to waste more time on style discussions about code that
fixes other people's issues, and not the time to test the code on
Windows XP over and over again, I hope you are willing to accept code
that is different from how you would have written it. So it's take it
or leave it (or modify it yourself, if you feel like it).
--
Sebastian Schuberth
next prev parent reply other threads:[~2010-04-20 14:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-19 12:45 [PATCH] Fix checkout of large files to network shares under Windows XP Sebastian Schuberth
2010-04-19 20:41 ` Junio C Hamano
2010-04-20 9:15 ` Johannes Schindelin
2010-04-19 20:43 ` René Scharfe
2010-04-19 22:46 ` Albert Dvornik
2010-04-20 8:18 ` Johannes Sixt
2010-04-20 12:42 ` Sebastian Schuberth
2010-04-20 12:57 ` Johannes Sixt
2010-04-20 14:21 ` Sebastian Schuberth [this message]
2010-04-20 20:49 ` René Scharfe
2010-04-29 20:01 ` René Scharfe
2010-04-30 8:46 ` Johannes Sixt
2010-04-30 9:08 ` Sebastian Schuberth
[not found] ` <290b11b5-5dd5-4b83-a6f5-217797ebd5af@t8g2000yqk.googlegroups.com>
2010-10-16 17:23 ` René Scharfe
2010-10-17 10:54 ` Dmitry Potapov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=i2kbdca99241004200721l7cbd0052oa6921533f7efb8a4@mail.gmail.com \
--to=sschuberth@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=j.sixt@viscovery.net \
--cc=msysgit@googlegroups.com \
--cc=rene.scharfe@lsrfire.ath.cx \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).