From: Randall S. Becker <rsbecker@nexbridge.com>
Date: Sun, 08 Feb 2015 02:32:33 GMT
Subject: RE: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Message-ID: <020e01d04347$7efbe200$7cf3a600$@nexbridge.com>
In-Reply-To: <CAPc5daXD_7XZD5Vag51BjrSZ0q1r9eMswhLmnpUFqqjrc9oSTw@mail.gmail.com>

On Feb 7 2015 at 9:14 PM Junio C Hamano wrote:
>On Sat, Feb 7, 2015 at 2:31 PM, Joachim Schmitz <jojo@schmitz-digital.de> wrote:
>> Junio C Hamano <gitster <at> 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; otherwise
>>>  (3) use our internal default.
>>>
>>> And leave our internal default to 8MB.
>>>
>>> That way, nobody needs to do anything differently from his current 
>>> build
>> set-up,
>>> and I suspect that it would make step (1) optional.
>>
>> 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 < MAX_IO_SIZE) # undef MAX_IO_SIZE /* 
>> avoid warning */ # define MAX_IO_SIZE SSIZE_MAX #endif
>No, not like that. If you do (1), that is only so that the Makefile can override a broken definition a platform may give to SSIZE_MAX.  So
> (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 internal default.

That is reasonable. I am more concerned about our git-upload-pak (separate thread) anyway :)

Cheers, Randall