Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:50224 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 61151 invoked from network); 16 Nov 2010 04:21:27 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Nov 2010 04:21:27 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.123 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.123 smtp123.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.123] ([67.192.241.123:58476] helo=smtp123.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9C/3A-25603-4C602EC4 for ; Mon, 15 Nov 2010 23:21:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp22.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 0153E170430; Mon, 15 Nov 2010 23:21:20 -0500 (EST) X-Virus-Scanned: OK Received: by smtp22.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id B08671704E5; Mon, 15 Nov 2010 23:21:20 -0500 (EST) Message-ID: <4CE206C0.5070701@sugarcrm.com> Date: Mon, 15 Nov 2010 20:21:20 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Rasmus Lerdorf CC: internals References: <4CE03E41.9030805@lerdorf.com> <8757232E56758B42B2EE4F9D2CA019C9086B69@US-EX2.zend.net> <4CE10E8E.3070901@lerdorf.com> In-Reply-To: <4CE10E8E.3070901@lerdorf.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Adding path_len to all stream functions in trunk From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Ok, I went through all the 5.3 code. This should fix the null poisoning > problems in 5.3 without breaking binary compatibility: > > http://progphp.com/nullpatch.txt Looking at this patch, I wonder if it wouldn't be cleaner to add new type (string without nulls) in parameter parsing and have it handled by parameter parsing in one place instead of doing it in dozens of different places? There might be some other places not covered but it would cover most functions - and it's easier to catch/fix those in extensions. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227