Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-07 Thread Joachim Schmitz
Joachim Schmitz schmitz-digital.de> writes: > because xpread() returns something > 0. something < 0 of course (presumably -1)... bye, Jojo -- 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://vge

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-07 Thread Torsten Bögershausen
On 2015-02-07 17.45, Joachim Schmitz wrote: > Hi there > > While investigating the problem with hung git-upload-pack we think to have > found a bug in wrapper.c: > > #define MAX_IO_SIZE (8*1024*1024) > > This is then used in xread() to split read()s into suitable chunks. > So far so good, but r

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-07 Thread Joachim Schmitz
Torsten Bögershausen web.de> writes: > > On 2015-02-07 17.45, Joachim Schmitz wrote: > > How about changing wrapper.c like this: > > #ifndef MAX_IO_SIZE > #define MAX_IO_SIZE (8*1024*1024) > #endif > - > and to change config.mak.uname like this: > > ifeq ($(uname_S),NONS

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-07 Thread Joachim Schmitz
Joachim Schmitz schmitz-digital.de> writes: > > Torsten Bögershausen web.de> writes: > > > > > On 2015-02-07 17.45, Joachim Schmitz wrote: > b) never ever should read() be asked to read more than SSIZE_MAX, this > should be true for every platform on the planet? You may want to have is >

RE: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-07 Thread Randall S. Becker
On 2015-02-07 12:30PM Torsten Bögershausen wrote: >On 2015-02-07 17.45, Joachim Schmitz wrote: >> Hi there >> >> While investigating the problem with hung git-upload-pack we think to >> have found a bug in wrapper.c: >> >> #define MAX_IO_SIZE (8*1024*1024) >> >> This is then used in xread() to

RE: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-07 Thread Randall S. Becker
On 2015-02-07 13:07PM Randall S. Becker wrote: >On 2015-02-07 12:30PM Torsten Bögershausen wrote: >>On 2015-02-07 17.45, Joachim Schmitz wrote: >>> Hi there >>> >>> While investigating the problem with hung git-upload-pack we think to >>> have found a bug in wrapper.c: >>> >>> #define MAX_IO_SIZ

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-07 Thread Joachim Schmitz
Randall S. Becker nexbridge.com> writes: > > On 2015-02-07 13:07PM Randall S. Becker wrote: > >On 2015-02-07 12:30PM Torsten Bögershausen wrote: > >>On 2015-02-07 17.45, Joachim Schmitz wrote: > Although I do agree with Jojo, that MAX_IO_SIZE seems to be a platform > constant and should be def

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-07 Thread Joachim Schmitz
Joachim Schmitz schmitz-digital.de> writes: > and as a (rather strange) > consequence mmap() (from compat/mmap.c) fails with EACCESS (why EACCESS?), > because xpread() returns something > 0. Seems mmap() should either set errno to EINVAL or not set it at all an just 'forward' whatever xprea

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-07 Thread Torsten Bögershausen
On 2015-02-07 18.29, Joachim Schmitz wrote: > Torsten Bögershausen web.de> writes: > >> >> On 2015-02-07 17.45, Joachim Schmitz wrote: > >> >> How about changing wrapper.c like this: >> >> #ifndef MAX_IO_SIZE >> #define MAX_IO_SIZE (8*1024*1024) >> #endif >> - >> and to chan

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-07 Thread Junio C Hamano
On Sat, Feb 7, 2015 at 12:32 PM, Torsten Bögershausen wrote: > I don't know every platform of the planet well enough to be helpful here, > especially the ones which don't follow all the specifications. > > In other words: As long as we can not guarantee that SSIZE_MAX is defined, > (and is defined

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-07 Thread Joachim Schmitz
Junio C Hamano pobox.com> writes: > > On Sat, Feb 7, 2015 at 12:32 PM, Torsten Bögershausen web.de> wrote: > > I don't know every platform of the planet well enough to be helpful here, > > especially the ones which don't follow all the specifications. > > > > In other words: As long as we can

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-07 Thread Junio C Hamano
On Sat, Feb 7, 2015 at 2:31 PM, Joachim Schmitz wrote: > Junio C Hamano pobox.com> writes: >> >> Yup, I agree that is a sensible way to go. >> >> (1) if Makefile overrides the size, use it; otherwise >> (2) if SSIZE_MAX is defined, and it is smaller than our internal >> default, use it; otherwi

RE: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-07 Thread Randall S. Becker
On Feb 7 2015 at 9:14 PM Junio C Hamano wrote: >On Sat, Feb 7, 2015 at 2:31 PM, Joachim Schmitz >wrote: >> Junio C Hamano pobox.com> writes: >>> >>> Yup, I agree that is a sensible way to go. >>> >>> (1) if Makefile overrides the size, use it; otherwise >>> (2) if SSIZE_MAX is defined, and it

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-08 Thread Joachim Schmitz
Junio C Hamano pobox.com> writes: > > > > something like this: > > > > /* allow overwriting from e.g. Makefile */ > > #if !defined(MAX_IO_SIZE) > > # define MAX_IO_SIZE (8*1024*1024) > > #endif > > /* for plattforms that have SSIZE and have it smaller */ > > #if defined(SSIZE_MAX && (SSIZE_MAX <

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-08 Thread Eric Sunshine
On Sun, Feb 8, 2015 at 7:05 AM, Joachim Schmitz wrote: > Junio C Hamano pobox.com> writes: >> (1) if Makefile gives one, use it without second-guessing with SSIZE_MAX. >> (2) if SSIZE_MAX is defined, and if it is smaller than our internal >> default, use it. >> (3) all other cases, us our inte

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-11 Thread Junio C Hamano
Eric Sunshine writes: > A bit cleaner: > > #ifndef(MAX_IO_SIZE) > # define MAX_IO_SIZE_DEFAULT (8*1024*1024) > # if defined(SSIZE_MAX) && (SSIZE_MAX < MAX_IO_SIZE_DEFAULT) > # define MAX_IO_SIZE SSIZE_MAX > # else > # define MAX_IO_SIZE MAX_IO_SIZE_DEFAULT > # endif > #endif OK, then let's do

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-11 Thread Joachim Schmitz
Junio C Hamano pobox.com> writes: > OK, then let's do this. > Yep, that'd do, thanks. bye, Jojo -- 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

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-11 Thread Joachim Schmitz
Joachim Schmitz schmitz-digital.de> writes: > > Junio C Hamano pobox.com> writes: > > > > OK, then let's do this. > > Except for the type "taht" -- 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

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-11 Thread Junio C Hamano
Joachim Schmitz writes: > Joachim Schmitz schmitz-digital.de> writes: > >> >> Junio C Hamano pobox.com> writes: >> >> >> > OK, then let's do this. >> > > > > Except for the type "taht" Also #ifndef part X-< Here is what I queued for the day. -- >8 -- Subject: xread/xwrite: clip MAX_IO_S

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

2015-02-11 Thread Joachim Schmitz
Sorry to be a pain, but i think this sententence neede mending + * to override this, if the definition of SSIZE_MAX platform is broken. Bye, Jojo