Eric Sunshine <sunsh...@sunshineco.com> writes:
>> +# 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
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
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