Am 4/19/2010 22:43, schrieb René Scharfe:
quoted text
> Am 19.04.2010 14:45, schrieb Sebastian Schuberth:
>> +#undef write
>> +ssize_t mingw_write(int fd, const void *buf, size_t count)
>> +{
>> +	ssize_t written = 0;
>> +	size_t total = 0, size = count;
>> +
>> +	while (total < count && size > 0) {
>> +		written = write(fd, buf, size);
>> +		if (written < 0 && errno == EINVAL) {
>> +			// There seems to be a bug in the Windows XP network stack that
>> +			// causes writes with sizes > 64 MB to fail, so we halve the size
>> +			// until we succeed or ultimately fail.
> 
> C style comments (/*...*/) are preferred over C++ style comments (//...)
> for git.
> 
> Is there a known-good size, or at least a mostly-working one?  Would it
> make sense to start with that size instead of halving and trying until
> that size is reached?
> 
>> +			size /= 2;
>> +		} else {
>> +			buf += written;
>> +			total += written;
> 
> What about other errors?  You need to break out of the loop instead of
> adding -1 to buf and total, right?

Thanks for a thorough review. I had the gut feeling that something's wrong
with the code due to its structure, but didn't stare at the code long
enough to notice this.

I suggest to have this structure

	write
	if success or failure is not EINVAL
		return

	do
		reduce size
		if larger than known (presumed?) maximum
			reduce to that maximum
		write
	while not success and failure is EINVAL

	while not failure and exactly reduced size written
		write more

I don't think that we will observe any short writes *after* the size was
reduced, which Albert is concerned about. Somebody who observes the
failure that this works around could instrument the function to see
whether short writes are really a problem.

-- Hannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html