Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 98248 invoked by uid 500); 23 Apr 2003 18:57:27 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 98190 invoked from network); 23 Apr 2003 18:57:26 -0000 Message-ID: <3EA6E255.6050105@attglobal.net> Date: Wed, 23 Apr 2003 14:58:29 -0400 From: Jeff Trawick Reply-To: trawick@attglobal.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: [PATCH] mod_cgi and logging References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Roy T. Fielding wrote: >> yep... IMHO it would be nice if apr_file_gets() didn't return APR_EOF >> when it reads a line with no terminating '\n' but I bitched about this >> behavior recently and nobody offered an opinion pro/con so I think >> we're stuck with it :) > > > Why? Just fix it. +1 it just brings back unfond memories of the notion that APR would potentially return non-APR_SUCCESS when data was read... yuck yes, I should "fix" it and see who hollers it won't break most apps, since with the old behavior an app had to check whether or not they got data with APR_EOF anyway