[PATCH] imap_savebody()

Yep, I agree with that, and some past tests of mine showed that depending on the system, anything bigger than about 8-64K, will give marginal performance increase (and possibly decrease depending on memory allocation); so it's really not worth the hassle. It's also a size which we can allocate on the stack. Andi At 09:52 AM 9/22/2005, Wez Furlong wrote:

Looks basicly alright (with a slight disagreement on how the read loop is implemented (below). In general you've got my vote (for what it's worth given my lack of experience with libc-client. unsigned long i, rest = size % GETS_FETCH_SIZE; char *buf = emalloc(GETS_FETCH_SIZE+1); for (i = GETS_FETCH_SIZE; i < size; i += GETS_FETCH_SIZE) { memset(buf, 0, GETS_FETCH_SIZE+1); f(stream, GETS_FETCH_SIZE, buf); php_stream_write_string(IMAPG(gets_stream), buf); } if (rest) { memset(buf, 0, GETS_FETCH_SIZE+1); f(stream, rest, buf); php_stream_write_string(IMAPG(gets_stream), buf); } efree(buf); return NULL; Here's how I'd write this block, it assumed that f returns the number of bytes actually read, but according to the proto for readfn_t it *should* do that. Feel free to ignore: char buf[GETS_FETCH_SIZE]; unsigned long ret = 1; while (ret > 0) { ret = f(stream, GETS_FETCH_SIZE, buf); php_stream_write_stringl(IMAPG(gets_stream), buf, ret); } return NULL;