Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:50191 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 5911 invoked from network); 14 Nov 2010 19:53:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Nov 2010 19:53:44 -0000 Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.210.42 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 209.85.210.42 mail-pz0-f42.google.com Received: from [209.85.210.42] ([209.85.210.42:52507] helo=mail-pz0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FF/F0-21571-64E30EC4 for ; Sun, 14 Nov 2010 14:53:43 -0500 Received: by pzk27 with SMTP id 27so896797pzk.29 for ; Sun, 14 Nov 2010 11:53:40 -0800 (PST) Received: by 10.142.233.4 with SMTP id f4mr3777687wfh.60.1289764419995; Sun, 14 Nov 2010 11:53:39 -0800 (PST) Received: from Anonymous.local ([66.201.49.171]) by mx.google.com with ESMTPS id v19sm7657533wfh.12.2010.11.14.11.53.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 14 Nov 2010 11:53:39 -0800 (PST) Message-ID: <4CE03E41.9030805@lerdorf.com> Date: Sun, 14 Nov 2010 11:53:37 -0800 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: internals X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Adding path_len to all stream functions in trunk From: rasmus@lerdorf.com (Rasmus Lerdorf) I think we need to pass along the string length to all the stream functions to maintain binary string safety through this code. This would fix annoying problems like http://bugs.php.net/39863 and a bunch of similar issues. Obviously not something we can do in 5.3 without breaking binary compatibility though. Although we might be able to do something if we assume only chars valid in the current charset is valid in file paths. Anybody have any other thoughts on this one? -Rasmus