Date: Sat, 16 Feb 2013 04:08:06 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Jilles Tjoelker <jilles@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r246824 - head/lib/libc/stdio Message-ID: <20130216024443.N1029@besplex.bde.org> In-Reply-To: <201302151044.r1FAi8rs010160@svn.freebsd.org> References: <201302151044.r1FAi8rs010160@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. - 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). 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. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130216024443.N1029>