Date: Wed, 7 May 2008 21:39:05 -0400 From: Garrett Wollman <wollman@bimajority.org> To: Alfred Perlstein <alfred@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/include stdio.h src/lib/libc/stdio clrerr.c feof.c ferror.c fileno.c getc.c getchar.c local.h putc.c putchar.c xprintf.c Message-ID: <18466.22969.506620.244442@hergotha.csail.mit.edu> In-Reply-To: <20080507231444.GF32532@elvis.mu.org> References: <200805051603.m45G3rrN089219@repoman.freebsd.org> <200805051637.43073.jhb@freebsd.org> <20080507064013.GU32532@elvis.mu.org> <200805071111.39938.jhb@freebsd.org> <20080507231444.GF32532@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Wed, 7 May 2008 16:14:44 -0700, Alfred Perlstein <alfred@FreeBSD.org> said: > I don't think that's really fair, stdio has had adequate accessors > for a long time Actually, no it hasn't. std stdio does not provide visibility into its internal buffering state so that implementations would not be constrained. This does not mean that useful applications would never want to access this information, only that accessing it is not Portable-with-a-capital-P. (Many of these applications implement things which are inherently not Portable anyway, like garbage collection.) I like the idea of making FILE opaque, in the abstract, but it does come with some very real costs, and if we're not prepared to pay those costs, we need to leave FILE translucent at the very least. (At least we can be certain that only the library ever allocates a FILE object, which isn't the case for some other warty interfaces.) -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18466.22969.506620.244442>