Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!garnet.berkeley.edu!ked
From: ked@garnet.berkeley.edu (Earl H. Kinmonth)
Newsgroups: comp.unix.xenix
Subject: setvbuf() broken under SCO Xenix?
Message-ID: <21590@agate.BERKELEY.EDU>
Date: 14 Mar 89 05:07:46 GMT
Sender: usenet@agate.BERKELEY.EDU
Reply-To: ked@garnet.berkeley.edu (Earl H. Kinmonth)
Organization: University of California, Berkeley
Lines: 35

Several weeks ago, I posted a note to the effect that SCO Xenix
setvbuf is screwed up compared to more common setvbuf versions
because of the different calling conventions:

setvbuf(stream,buf,type,size)	/* common */

setvbuf(stream,type,buf,size)	/* sco */

I thought fixing this would correct some problems I had noted
with programs converted from 4.3 BSD or even MiSerable DOS.  This
has not been the case.  I've noted several instances of weird bugs
when using setvbuf() with SCO Xenix (the same programs run fine with
MiSerable DOS and 4.3 BSD).  They also run fine under SCO Xenix IF
setvbuf is commented out of the code. Specifically:

(a)
buf = malloc(size);
setvbuf(stream,type,buf,size);
stream->_flag & _IOMYBUF shows that _IOMYBUF is not set.

(b)
measured performance with sequential access (getc()) on large files
shows no improvement, even a degradation with size > BUFSIZ!  This
is disturbing, since MiSerable DOS and 4.3 BSD show improved performance
(elapsed time, number of calls to read()) with larger buffer sizes.

This suggests to me that not only is the parameter sequence for
setvbuf() assbackwards, but the actual realization of the function
is broken.

Note, to detect this, you must use prof and/or look at the times needed
to read/write a file.  Bad calls to setvbuf() apparently do no harm,
and the first io operation on stream gives you default buffering, so
unless you are making cross comparisons between systems, you probably
will see no problems.