Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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 > 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. -- 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