Re: write() _will_ fail on Mac OS X/XNU if nbytes > INT_MAX

2013-11-20 Thread Torsten Bögershausen
Hej, I think the patch went in and out in git.git, please see below. (I coudn't the following in msysgit, but if it was there, the clipped_write() for Windows could go away. /Torsten commit 0b6806b9e45c659d25b87fb5713c920a3081eac8 Author: Steffen Prohaska Date: Tue Aug 20 08:43:54 2013 +0

Re: write() _will_ fail on Mac OS X/XNU if nbytes > INT_MAX

2013-11-20 Thread Erik Faye-Lund
I know I'm extremely late to the party, and this patch has already landed, but... On Sat, May 11, 2013 at 1:05 AM, Junio C Hamano wrote: > Filipe Cabecinhas writes: > >> Due to a bug in the Darwin kernel, write() calls have a maximum size of >> INT_MAX bytes. >> >> This patch introduces a new co

Re: write() _will_ fail on Mac OS X/XNU if nbytes > INT_MAX

2013-05-10 Thread Junio C Hamano
Filipe Cabecinhas writes: > It compiles cleanly and runs. I'm running the test suite anyway, but > don't expect any change from your latest patch. Heh, I do not think we did write(2) of that many bytes in our test suite ;-) Thanks. -- To unsubscribe from this list: send the line "unsubscribe gi

Re: write() _will_ fail on Mac OS X/XNU if nbytes > INT_MAX

2013-05-10 Thread Filipe Cabecinhas
Hi Junio, It compiles cleanly and runs. I'm running the test suite anyway, but don't expect any change from your latest patch. Thank you, Filipe F On Fri, May 10, 2013 at 4:13 PM, Filipe Cabecinhas wrote: > Hi Junio, > > Thanks for helping. Your text is correct and only diffs from my patc

Re: write() _will_ fail on Mac OS X/XNU if nbytes > INT_MAX

2013-05-10 Thread Filipe Cabecinhas
Hi Junio, Thanks for helping. Your text is correct and only diffs from my patch in the #define write(...) part, where I suppose you stripped the spaced in the arglist. Thank you, Filipe F On Fri, May 10, 2013 at 4:05 PM, Junio C Hamano wrote: > Filipe Cabecinhas writes: > >> Due to a bu

Re: write() _will_ fail on Mac OS X/XNU if nbytes > INT_MAX

2013-05-10 Thread Junio C Hamano
Junio C Hamano writes: > Also I have a small suggestion I'd like you to try on top of it, > which I'll be sending in a separate message. The first hunk is to match other Makefile knobs the builders can tweak with minimum documentation. As you hinted that there may be other platforms that may wa

Re: write() _will_ fail on Mac OS X/XNU if nbytes > INT_MAX

2013-05-10 Thread Junio C Hamano
Filipe Cabecinhas writes: > Due to a bug in the Darwin kernel, write() calls have a maximum size of > INT_MAX bytes. > > This patch introduces a new compat function: clipped_write > This function behaves the same as write() but will write, at most, INT_MAX > characters. > It may be necessary to i

Re: write() _will_ fail on Mac OS X/XNU if nbytes > INT_MAX

2013-05-10 Thread Filipe Cabecinhas
Due to a bug in the Darwin kernel, write() calls have a maximum size of INT_MAX bytes. This patch introduces a new compat function: clipped_write This function behaves the same as write() but will write, at most, INT_MAX characters. It may be necessary to include this function on Windows, too. Si

Re: write() _will_ fail on Mac OS X/XNU if nbytes > INT_MAX

2013-05-09 Thread Junio C Hamano
Filipe Cabecinhas writes: > Sorry for the delay. I've updated the patch to work as you suggested (I > think). > It's attached. A few comments. First, the formalities. Please see Documentation/SubmittingPatches, notably: - Please do not send a patch as an attachment. - The attached pat

Re: write() _will_ fail on Mac OS X/XNU if nbytes > INT_MAX

2013-05-09 Thread Filipe Cabecinhas
Hi Junio, Sorry for the delay. I've updated the patch to work as you suggested (I think). It's attached. Thank you, Filipe F On Tue, Apr 9, 2013 at 3:50 PM, Junio C Hamano wrote: > Filipe Cabecinhas writes: > >> >> Testing with dd bs=INT_MAX+1 count=1 also gets me an “Invalid >> argument

Re: write() _will_ fail on Mac OS X/XNU if nbytes > INT_MAX

2013-04-09 Thread Junio C Hamano
Filipe Cabecinhas writes: > > Testing with dd bs=INT_MAX+1 count=1 also gets me an “Invalid > argument” error, while bs=INT_MAX will do what's expected. > > I have a preliminary patch that fixes it, but it may not be the > preferred way. The code is not ifdef'ed out and I'm doing the fix in > wri