Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!purdue!decwrl!ucbvax!ucbarpa.Berkeley.EDU!edward
From: edward@ucbarpa.Berkeley.EDU (Edward Wang)
Newsgroups: comp.unix.wizards
Subject: Re: Is Unix stdio slow?
Message-ID: <26330@ucbvax.BERKELEY.EDU>
Date: 5 Oct 88 00:42:00 GMT
References: <411@marob.MASA.COM> <178@arnold.UUCP> <3442@crash.cts.com> <26315@ucbvax.BERKELEY.EDU> <13853@mimsy.UUCP>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: edward@ucbarpa.Berkeley.EDU.UUCP (Edward Wang)
Organization: University of California, Berkeley
Lines: 15

In article <13853@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>. . . _doprnt
>assumes that a negative _cnt field is an error, and clobbers the
>count.  Every once in a while, this results in putc scribbling all over
>memory.  Fortunately, instances of this bug are rare (it requires
>mixing calls to printf and calls to putc in a particular way).  This is
>fixed in 4.3BSD-tahoe, which no longer has _doprnt in Vax assembly.

Well I don't know about this, but the negative _cnt field
is as old as line buffering, before the fast putc.  The old
putc depended on the negative _cnt to invoked _flsbuf
for line buffered streams (the --fp->_cnt >= 0 test always
fails so _flsbuf is always called).

But enough on this already.