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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Feb 7, 2015 at 2:31 PM, Joachim Schmitz <jojo@xxxxxxxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]