[PATCH] Do not break buffers in fvwrite for unbuffered files

[Corinna Vinschen]

On Oct 21 14:19, Federico wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 10/21/2013 01:54 PM, Corinna Vinschen wrote:
> > On Oct 21 10:36, Federico wrote:
> >> -	  w = fp->_write (ptr, fp->_cookie, p, MIN (len, BUFSIZ)); +
> >> w = fp->_write (ptr, fp->_cookie, p, len);
> > 
> > As noted in my other reply, len is size_t but the parameter to
> > _write may be int, even after my _READ_WRITE_BUFSIZE_TYPE patch has
> > been applied.
> > 
> > Therefore the type size difference still has to be accounted for. 
> > Maybe something like this is sufficient:
> > 
> > w = fp->_write (ptr, fp->_cookie, p, MIN (len, MAX_INT));
> > 
> > ???
> > 
> > 
> > Thanks, Corinna
> > 
> 
> First of all I'm happy to know that my profiling work is useful to
> other targets as well.
> Thanks for the patch review, didn't notice the type problem as my
> target still uses int for file offsets.
> Your solution using MAX_INT is more than satisfactory, as it would
> only split *really* large buffers in 2GByte chunks. In my target
> (microcontrollers with limited RAM amount), this will simply never
> happen, while on other targets the overhead of one syscall every
> 2GByte is probably of no concern.

Maye it makes sense to use the largest multiple  of BUFSIZ <= MAX_INT.
See below.
> 
> I'm wondering if it makes sense to avoid splitting writes (and reads)
> also for buffered files. glibc appears to do it,

Buffered writes are already split into fp->_bf._size chunks.  Glibc
basically uses the largest multiple of fp->_bf._size <= len instead.
We could do the same.  Would you like to create a patch for that?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20131021/59f66bb7/attachment.sig>