Path: utzoo!mnetor!uunet!mcvax!ukc!eagle!icdoc!cam-cl!am From: am@cl.cam.ac.uk (Alan Mycroft) Newsgroups: comp.lang.c Subject: Re: closing stdout Message-ID: <1115@jenny.cl.cam.ac.uk> Date: 9 Dec 87 10:38:55 GMT References: <442@cresswell.quintus.UUCP> Reply-To: am@cl.cam.ac.uk (Alan Mycroft) Organization: U of Cambridge Comp Lab, UK Lines: 19 Keywords: Yes it IS a buggy library In article <442@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >There's an old joke with the punch-line "We've already established what >you are, madam. Now we're just haggling over the price." > result = getchar(); > errno = 0; > result = putc(result, stdin); > printf("result = %d, errno = %d\n", result, errno); >The bug is that depending on where you are in the buffer, putc() MIGHT >notice the mistake, but it usually won't. >... the bug is a pretty fundamental one in the UNIX stdio implementation, Richard, The bug is not in the slightest bit fundamental and could be fixed in less than 1 day once and for all. I have done it for a ANSI unix-like I/O library: Merely separate the _cnt field of struct FILE into a _icnt and an _ocnt, change getc/putc to use _icnt/_ocnt. Fix _filbuf/_flsbuf to use the right one, and to whinge when _icnt/_ocnt goes -ve when you expect the other one to. This for free also enables the library to police the "fflush/fseek between change of direction for I/O" restriction and avoids chaos there.