Re: [PATCH v3] compat: Fix read() of 2GB and more on Mac OS X

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 19, 2013, 16:33 UTC
Message-ID: <7veh9pmyin.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAPig+cTr_B+vtN4sFzepWeW4TpRPD9eKnjy08yJ2pf3KfVU1XA@mail.gmail.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

Show 9 quoted lines

>> +# Define NEEDS_CLIPPED_READ if your read(2) cannot read more than
>> +# INT_MAX bytes at once (e.g. MacOS X).
>> +#
>>  # Define NEEDS_CLIPPED_WRITE if your write(2) cannot write more than
>>  # INT_MAX bytes at once (e.g. MacOS X).
>
> Is it likely that we would see a platform requiring only one or the
> other CLIPPED? Would it make sense to combine these into a single
> NEEDS_CLIPPED_IO?

I am slightly negative to that suggestion for two reasons.

 - Does MacOS X clip other IO operations?  Do we need to invent yet
   another NEEDS_CLIPPED, e.g. NEEDS_CLIPPED_LSEEK?

   A single NEEDS_CLIPPED_IO may sound attractive for its simplicity
   (e.g. on a system that only needs NEEDS_CLIPPED_WRITE, we will
   unnecessarily chop a big read into multiple reads, but that does
   not affect the correctness of the operation, only performance but
   the actual IO cost will dominate it anyway).  If we know there
   are 47 different IO operations that might need clipping, that
   simplicity is certainly a good thing to have.  I somehow do not
   think the set of operations will grow that large, though.

 - NEEDS_CLIPPED_IO essentially says "only those who clip their
   writes would clip their reads (and vice versa)", which is not all
   that different from saying "only Apple would clip their IO",
   which in turn defeats the notion of "let's use a generic
   NEEDS_CLIPPED without limiting the workaround to specific
   platforms" somewhat.