Date: Mon, 8 Mar 2004 23:32:08 -0500 From: Alexander Kabaev <ak03@gte.com> To: John Birrell <jb@cimlogic.com.au> Cc: src-committers@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/stdio _flock_stub.c local.h Message-ID: <20040309043207.GA65153@kanpc.gte.com> In-Reply-To: <20040309150536.R234@freebsd3.cimlogic.com.au> References: <200403090245.i292j0a6035728@repoman.freebsd.org> <20040309032248.GA88649@cat.robbins.dropbear.id.au> <20040309143223.Q234@freebsd3.cimlogic.com.au> <20040309035532.GA88825@cat.robbins.dropbear.id.au> <20040309150536.R234@freebsd3.cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 09, 2004 at 03:05:36PM +1100, John Birrell wrote: > > I'm not sure that I agree that applications are 'broken' when they > use things that are defined in the header file along with the FILE > structure itself. I would like to see FILE to become transparent to applications and its definition moved to the libc-private header file with the specific purpose of making the hack you mentioned impossible. Are there any other means for you to achieve what you want? Can funopen be used to simulate stdio stream instead? > As I said in my previous mail, if you want to improve performance, > then remove the locking code from libc completely in the single-threaded > case. That will have more benefit than checking a NULL pointer that > has to be resolved anyway in order to access the fields it points > to. I think you're arguing about just a few instructions on i386. > I agree that handful of extra instruction won't make stdio much slower. Rather, I object to your change because it allows applications to become dependant on intimate knowledge of FILE internals which means inevitable ABI breakages and associated headaches in the future. -- Alexander Kabaev
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040309043207.GA65153>