Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 90745 invoked from network); 23 Aug 2007 20:14:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 Aug 2007 20:14:20 -0000 Received: (qmail 21765 invoked by uid 500); 23 Aug 2007 20:14:13 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 21712 invoked by uid 500); 23 Aug 2007 20:14:13 -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: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 21701 invoked by uid 99); 23 Aug 2007 20:14:13 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Aug 2007 13:14:13 -0700 Received-SPF: pass (athena.apache.org: local policy) Received: from [209.133.199.10] (HELO jimsys.jagunet.com) (209.133.199.10) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Aug 2007 20:14:16 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by jimsys.jagunet.com (Postfix) with ESMTP id 1E2FBA4EFE3 for ; Thu, 23 Aug 2007 16:13:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <46CDE878.6010600@rowe-clan.net> References: <20070823001036.0266B1A981A@eris.apache.org> <46CDD56B.1080505@apache.org> <46CDE005.7050602@rowe-clan.net> <46CDE781.9030707@apache.org> <46CDE878.6010600@rowe-clan.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <55FBF8CE-DA13-4018-B39B-EAA394D5F523@jaguNET.com> Content-Transfer-Encoding: 7bit From: Jim Jagielski Subject: Re: svn commit: r568779 - /httpd/httpd/trunk/server/main.c Date: Thu, 23 Aug 2007 16:13:55 -0400 To: dev@httpd.apache.org X-Mailer: Apple Mail (2.752.2) X-Virus-Checked: Checked by ClamAV on apache.org On Aug 23, 2007, at 4:05 PM, William A. Rowe, Jr. wrote: > Ruediger Pluem wrote: >> >> But I admit that this is harder to audit and is more likely to >> change at some >> point of time to the usage of a pool. > > More to the point, implementation of apr_ctime. The alternative of > no error > at all or no timestamp seemed worse, to me. Maybe an XXX comment > on trunk > to that effect? (I don't so much care about 0.9/1.2 which aren't > moving > targets, like trunk). Yeah, the conditions and assumptions on which this is based warrant some comments in the code :)