On Sat, Feb 16, 2013 at 04:08:06AM +1100, Bruce Evans wrote: > On Fri, 15 Feb 2013, Jilles Tjoelker wrote:
> > Log: > > setbuf(3): Remove bugs section about ancient versions of BSD. > > Modified: > > head/lib/libc/stdio/setbuf.3 > > Modified: head/lib/libc/stdio/setbuf.3 > > ============================================================================== > > --- head/lib/libc/stdio/setbuf.3 Fri Feb 15 09:10:01 2013 > > (r246823) > > +++ head/lib/libc/stdio/setbuf.3 Fri Feb 15 10:44:07 2013 > > (r246824) > > ... > > @@ -195,19 +195,3 @@ and > > functions > > conform to > > .St -isoC . > > -.Sh BUGS > > -The > > -.Fn setbuffer > > -and > > -.Fn setlinebuf > > -functions are not portable to versions of > > -.Bx > > -before > > -.Bx 4.2 . > > -On > > -.Bx 4.2 > > -and > > -.Bx 4.3 > > -systems, > > -.Fn setbuf > > -always uses a suboptimal buffer size and should be avoided. > This also removes the bugs section about setbuf() being unusable. It > uses a buffer of size BUFSIZ, but that is unusably small. This bug > is older than the old versions of BSD (setbuf() was broken as designed) > but still applies. So I should put back a BUGS section with the below? ] .Fn setbuf ] always uses a suboptimal buffer size and should be avoided. The risk is not very high because the lazy thing to do (not calling setbuf() at all) gives better results than calling setbuf(). > BTW, I recently noticed many utilities using too-small stdio buffers: > - md5(1) and libmd use raw BUFSIZ to get the same slowness as setbuf(). > They even try to get misaligned buffers by allocating them as char > arrays on they stack. md5(1) calls fread() for BUFSIZ bytes at a time. This causes more memory copies than necessary but does not affect the stdio buffer size passed to read(2). > - cmp(1) in the non-regular file case naively believe that stdio chooses > a good buffer size, and stdio naively believes that stat()'s > st_blksize is a good buffer size. The latter is still broken in the > kernel (it was unbroken a couple of years ago for regular files). Any way to fix stdio? > So cmp [-lx] on disks runs very slowly. cmp's internal algorithms > are also very slow (starting with using stdio at all), but can keep > up with disks provided the disks are slowed down like this. The > non-regular file case is little better. It uses mmap() and a > different slow internal algorithm (not quite as slow since it doesn't > use stdio). mmap() is especially suitable for disk files, but cmp > "knows" that it only works on regular files. cp(1) and install(1) use > mmap() more reasonably. mmap() is generally worse than read()/write() if you only access the data once. VM manipulations are not free. In the interest of simplicity it may be good to remove the extra code and only use read()/write(). -- Jilles Tjoelker _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
