svn commit: r246824 - head/lib/libc/stdio

[Jilles Tjoelker]

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