peter@ficc.uu.net (Peter da Silva) (09/26/88)
In article <13733@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
[ a bunch of stuff including a reference to line buffered output ]
It always depresses me when I think that people are still doing line
buffered output. The problem of handling stdout and stdin is a solved
problem: do a flushbuf on all interactive streams whenever you do a
fillbuf on any interactive stream. This would also make 90% of the explicit
calls to fflush() unnecessary, since most of them are something like:
printf("Command> ");
fflush(stdout);
gets(buffer);
AND it's more efficient since it takes that test out of putchar!
--
Peter da Silva `-_-' Ferranti International Controls Corporation.
"Have you hugged U your wolf today?" peter@ficc.uu.netchris@mimsy.UUCP (Chris Torek) (09/28/88)
In article <1613@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >It always depresses me when I think that people are still doing line >buffered output. The problem of handling stdout and stdin is a solved >problem: do a flushbuf on all interactive streams whenever you do a >fillbuf on any interactive stream. ... `Backwards compatibility means we get to keep all our old mistakes.' I guarantee that if we change this in 4.4BSD, people will complain about how we broke it. (I am considering adding a separate macro for putc-without-newline-flush to the local stdio.h. This is backward-compatible. It is also mildly gross. Then all we need do is convince the C compiler to migrate `==' tests across ?: boundaries, if one of the subexpressions turns it into a degenerate case.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
peter@ficc.uu.net (Peter da Silva) (10/03/88)
In article <13765@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > In article <1613@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >The problem of handling stdout and stdin is a solved > >problem: do a flushbuf on all interactive streams whenever you do a > >fillbuf on any interactive stream. ... > `Backwards compatibility means we get to keep all our old mistakes.' > I guarantee that if we change this in 4.4BSD, people will complain about > how we broke it. But it's *Berkeley* that had the smart stdio in the first place! I know that I ran into this on 2.something at Berkeley in 1980 and thought it was way-cool. When and why was it removed, or did it just not get migrated to 4BSD? And providing another putc won't help 'printf("%s-> ", mode);' and other prompt-like stuff. Nor will it help the overall speed problem. Sideways compatibility? -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net
chris@mimsy.UUCP (Chris Torek) (10/05/88)
>>In article <1613@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >>>The problem of handling stdout and stdin is a solved >>>problem: do a flushbuf on all interactive streams whenever you do a >>>fillbuf on any interactive stream. ... >In article <13765@mimsy.UUCP> I wrote: >>`Backwards compatibility means we get to keep all our old mistakes.' In article <1686@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: >But it's *Berkeley* that had the smart stdio in the first place! I know >that I ran into this on 2.something at Berkeley in 1980 and thought it >was way-cool. When and why was it removed, or did it just not get migrated >to 4BSD? I presume by `it' you mean that reading from stdin flushes stdout. That is still there; the difference between REALLY line buffered and fully-buffered-but-flushed-on-input can be seen with the following program: main() { putchar('g'); putchar('o'); putchar('\n'); for (;;); } 2BSD and 4BSD will both print `go\n' if stdout is a terminal, while under what I think you were proposing, you would never see anything. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
edward@ucbarpa.Berkeley.EDU (Edward Wang) (10/05/88)
In article <1686@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >[about flushing stdout when reading stdin] >But it's *Berkeley* that had the smart stdio in the first place! I know >that I ran into this on 2.something at Berkeley in 1980 and thought it >was way-cool. When and why was it removed, or did it just not get migrated >to 4BSD? That was in Berkeley Pascal.
peter@ficc.uu.net (Peter da Silva) (10/05/88)
In article <26327@ucbvax.BERKELEY.EDU>, edward@ucbarpa.Berkeley.EDU (Edward Wang) writes: > In article <1686@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >[about flushing stdout when reading stdin] > >But it's *Berkeley* that had the smart stdio in the first place! I know > >that I ran into this on 2.something at Berkeley in 1980 and thought it > >was way-cool. When and why was it removed, or did it just not get migrated > >to 4BSD? > That was in Berkeley Pascal. No, it was in 'C', on at least one version of 2.x BSD. I know because I got burned depending on it when I ported 'C' programs that didn't do an fflush() after a prompt. I never used Berkeley Pascal on version 7 (though I did use it on V6 until Ken Arnold convinced me 'C' was cooler. I do seem to remember that you always had to fflush(stdout) using the -lS libraries under V6, but that I won't swear to). -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net
peter@ficc.uu.net (Peter da Silva) (10/05/88)
In article <13866@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > main() { putchar('g'); putchar('o'); putchar('\n'); for (;;); } > 2BSD and 4BSD will both print `go\n' if stdout is a terminal, while > under what I think you were proposing, you would never see anything. I wouldn't expect to see anything in this program. I'm a good boy and always fflush() when I know I'm going to be going away for a while. Do you bother to fflush() before a fork()? Why not? Oh well, I suppose you have good reasons for what you do. I just wish you'd let me turn it off so I can really cook. How does this all interact with curses, which generates newlines essentially at random? Flushes at the newline and then an explicit flush when update completes? -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net
henry@utzoo.uucp (Henry Spencer) (10/06/88)
In article <13765@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > `Backwards compatibility means we get to keep all our old mistakes.' > I guarantee that if we change this in 4.4BSD, people will complain about > how we broke it. Hey, that's never stopped Berkeley before! :-) -- The meek can have the Earth; | Henry Spencer at U of Toronto Zoology the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu