xread/xwrite: clip MAX_IO_SIZE to SSIZE_MAX

Since 0b6806b9 (xread, xwrite: limit size of IO to 8MB, 2013-08-20), we chomp our calls to read(2) and write(2) into chunks of MAX_IO_SIZE bytes (8 MiB), because a large IO results in a bad latency when the program needs to be killed. This also brought our IO below SSIZE_MAX, which is a limit POSIX allows read(2) and write(2) to fail when the IO size exceeds it, for OS X, where a problem was originally reported. However, there are other systems that define SSIZE_MAX smaller than our default, and feeding 8 MiB to underlying read(2)/write(2) would fail. Make sure we clip our calls to the lower limit as well. Reported-by: Joachim Schmitz <jojo@schmitz-digital.de> Helped-by: Torsten Bögershausen <tboegi@web.de> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Junio C Hamano committed Feb 11, 2015 at 13:13 UTC a983e6ac58094a3b2466ad3be13049ce213f9fc3
1 file changed +15 -1
wrapper.c
+15 -1
@@ -135,8 +135,22 @@ void *xcalloc(size_t nmemb, size_t size)
135 * 64-bit is buggy, returning EINVAL if len >= INT_MAX; and even in
136 * the absense of bugs, large chunks can result in bad latencies when
137 * you decide to kill the process.
138 + *
139 + * We pick 8 MiB as our default, but if the platform defines SSIZE_MAX
140 + * that is smaller than that, clip it to SSIZE_MAX, as a call to
141 + * read(2) or write(2) larger than that is allowed to fail. As the last
142 + * resort, we allow a port to pass via CFLAGS e.g. "-DMAX_IO_SIZE=value"
143 + * to override this, if the definition of SSIZE_MAX given by the platform
144 + * is broken.
145 */
139 -#define MAX_IO_SIZE (8*1024*1024)
146 +#ifndef MAX_IO_SIZE
147 +# define MAX_IO_SIZE_DEFAULT (8*1024*1024)
148 +# if defined(SSIZE_MAX) && (SSIZE_MAX < MAX_IO_SIZE_DEFAULT)
149 +# define MAX_IO_SIZE SSIZE_MAX
150 +# else
151 +# define MAX_IO_SIZE MAX_IO_SIZE_DEFAULT
152 +# endif
153 +#endif
154
155 /*
156 * xread() is the same a read(), but it automatically restarts read()