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

["Randall S. Becker" <rsbecker@nexbridge.com>]

On 2015-02-07 13:07PM Randall S. Becker wrote:
>On 2015-02-07 12:30PM Torsten Bögershausen wrote:
>>On 2015-02-07 17.45, Joachim Schmitz wrote:
>>> Hi there
>>> 
>>> While investigating the problem with hung git-upload-pack we think to 
>>> have found a bug in wrapper.c:
>>> 
>>> #define MAX_IO_SIZE (8*1024*1024)
>>> 
>>> This is then used in xread() to split read()s into suitable chunks.
>>> So far so good, but read() is only guaranteed to read as much as 
>>> SSIZE_MAX bytes at a time. And on our platform that is way lower than 
>>> those 8MB (only 52kB, POSIX allows it to be as small as 32k), and as a 
>>> (rather strange) consequence mmap() (from compat/mmap.c) fails with 
>>> EACCESS (why EACCESS?), because xpread() returns something > 0.
>>> 
>>> How large is SSIZE_MAX on other platforms? What happens there if you 
>>> try to
>>> read() more? Should't we rather use SSIZE_MAX on all platforms? If I'm 
>>> reading the header files right, on Linux it is LONG_MAX (2TB?), so I 
>>> guess we should really go for MIN(8*1024*1024,SSIZE_MAX)?
>>How about changing wrapper.c like this: 
>>#ifndef MAX_IO_SIZE
>> #define MAX_IO_SIZE (8*1024*1024)
>>#endif
>>---------------------

Although I do agree with Jojo, that MAX_IO_SIZE seems to be a platform
constant and should be defined in terms of SSIZE_MAX. So something like:

#ifndef MAX_IO_SIZE
# ifdef SSIZE_MAX
#  define MAX_IO_SIZE (SSIZE_MAX)
# else
#  define MAX_IO_SIZE (8*1024*1024)
# endif
#endif

would be desirable.

Cheers, Randall