Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!uwvax!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Is Unix stdio slow?
Message-ID: <13853@mimsy.UUCP>
Date: 4 Oct 88 15:22:03 GMT
References: <411@marob.MASA.COM> <178@arnold.UUCP> <3442@crash.cts.com> <26315@ucbvax.BERKELEY.EDU>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 24

In article <26315@ucbvax.BERKELEY.EDU> edward@ucbarpa.Berkeley.EDU
(Edward Wang) writes:
>I should point out that [Chris Torek's expansion] is not 4.3 putc().
>The real 4.3 putc looks like this
>
>#define putc(x, p)	(--(p)->_cnt >= 0 ?\
>	(int)(*(unsigned char *)(p)->_ptr++ = (x)) :\
>	(((p)->_flag & _IOLBF) && -(p)->_cnt < (p)->_bufsiz ?\
[rest deleted]
>The block buffered path is the second line and does not
>check the _IOLBF bit.  It is, in fact, exactly as fast
>as the old putc.  Of course this doesn't mean the C compiler
>generates good code for it.

And, also of course, it does not mean that the code is right!  4.3BSD
putc and printf (actually _doprnt) do not speak to each other.  _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.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris