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.