Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:7603 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52356 invoked by uid 1010); 5 Feb 2004 07:37:08 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 52309 invoked from network); 5 Feb 2004 07:37:08 -0000 Received: from unknown (HELO colo.lerdorf.com) (66.198.51.121) by pb1.pair.com with SMTP; 5 Feb 2004 07:37:08 -0000 Received: from DELL (c-24-6-108-60.client.comcast.net [24.6.108.60]) by colo.lerdorf.com (8.12.11/8.12.11/Debian-1) with ESMTP id i157b0OB025036; Wed, 4 Feb 2004 23:37:01 -0800 Date: Wed, 4 Feb 2004 23:37:02 -0800 (Pacific Standard Time) To: Jon Parise cc: internals@lists.php.net In-Reply-To: <20040205071733.GA26688@csh.rit.edu> Message-ID: References: <20040205071733.GA26688@csh.rit.edu> X-X-Sender: rasmus@lerdorf.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on colo Subject: Re: [PHP-DEV] php-cgi command line switch memory check From: rasmus@php.net (Rasmus Lerdorf) On Thu, 5 Feb 2004, Jon Parise wrote: > Some additional archaeology says that this logic goes back to PHP 3 > (main.c revision 1.354, from 5 years, 11 months ago): > > http://cvs.php.net/diff.php/php3/main.c?login=2&r1=1.354&r2=1.355&ty=h > > I was kind of hoping it was something you had committed, but no such > luck. =) Well, it wouldn't have surprised me. I hit this all the time. I look at code and wonder who the moron was who wrote it and just before sending out a nastygram I doublecheck and find that I was that moron. In this case the check was added by Jaakko Hyvatti in February 98. Looking at the state of the code from back then I still don't see the reason why those switches were disallowed when running in a web context. We have to watch how we handle the query_string of course, but that doesn't seem like a difficult problem to address. -Rasmus