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
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
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
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
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
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
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 <
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
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
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
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
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
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
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
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
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
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
>
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
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
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
20 matches
Mail list logo
