Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 49267 invoked by uid 500); 3 Apr 2000 22:43:58 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 49250 invoked from network); 3 Apr 2000 22:43:56 -0000 From: Jim Jagielski Message-Id: <200004032243.SAA27417@devsys.jaguNET.com> Subject: Re: PATCH: APR buffered I/O To: new-httpd@apache.org Date: Mon, 3 Apr 2000 18:43:52 -0400 (EDT) Reply-To: jim@jaguNET.com In-Reply-To: <01ad01bf9db5$653867a0$0a1aa8c0@jetnet.co.uk> from "David Reid" at Apr 03, 2000 10:41:31 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Why support buffered I/O if we don't need it? :) David Reid wrote: > > So now you want to reopen the discussion about what belongs in APR again??? > > :-)) > > d. > ----- Original Message ----- > From: "Greg Stein" > To: > Sent: Monday, April 03, 2000 10:46 PM > Subject: Re: PATCH: APR buffered I/O > > > > I'm all for nuking buffered support. Why keep around (and maintain!) what > > isn't needed? > > > > [shades of proxy support arise...] > > > > The only factor for keeping it in would be the hypothetical future clients > > of APR. Would they *need* the support? Beats the crap outta me. I would > > think "probably". However, a better solution than buffered files may be > > bundling BUFF. > > > > Cheers, > > -g > > > > On Mon, 3 Apr 2000 rbb@apache.org wrote: > > > This patch brings up an interesting question. Do we even want to > support > > > buffered I/O in APR? We supported it originally because Apache needed > it > > > originally. Since then, Apache has removed ALL buffered I/O support, > and > > > the support in APR has fallen by the way-side. > > > > > > Just asking. > > > > > > Ryan > > > > > > On Mon, 3 Apr 2000, Greg Stein wrote: > > > > > > > Watch out for sign extension in ap_ungetc() !! > > > > > > > > It is quite possible that somebody passes in \xFF and the assignment > to > > > > ->ungetchar will sign-extend to -1. > > > > > > > > The assignment should look something like: > > > > > > > > thefile->ungetchar = (unsigned char)ch; > > > > > > > > Cheers, > > > > -g > > > > > > > > > > > > On Mon, 3 Apr 2000, Jon Travis wrote: > > > > > > > > > Attached are some patches to get ungetc() working in APR for > > > > > non-buffered > > > > > file descriptors. In addition, I believe I fixed a bug with the > > > > > ap_fgets() under > > > > > Unix (it looks like Win32 has it correct). I have tested out all > these > > > > > changes, > > > > > but please poke a careful eye into it anyway.. ;-) > > > > > > > > > > Also, I noticed that ap_seek() has arguments in reverse order from > what > > > > > UNIX > > > > > says that they should be. Perhaps we should change this for > consistancy > > > > > sake? > > > > > > > > > > -- Jon > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Greg Stein, http://www.lyra.org/ > > > > > > > > > > > > > > > > > > > > > > > > > > ____________________________________________________________________________ > ___ > > > Ryan Bloom rbb@apache.org > > > 406 29th St. > > > San Francisco, CA 94131 > > > > -------------------------------------------------------------------------- > ----- > > > > > > > -- > > Greg Stein, http://www.lyra.org/ > > > > > -- =========================================================================== Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/ "Are you suggesting coconuts migrate??"