Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50568
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=lJ6IVkWLxfE6+Wa9P1k5gIeNfKpYQaiD6p7FnoUL+LEm8S26pzvYaYj9VO2cG8WXvF
         Zh9V/+gfHVyiI28MaeMOC96MQHZ0XoSzHul5njSwM9e2Ai3BqyjkvQPsAWtbjmoE61U8
         5S4jbvpxDGh4UmLC4RejkX9VvfWpalukuZwyA=
MIME-Version: 1.0
In-Reply-To: <4CEEB07E.4050004@lerdorf.com>
References: <AANLkTi=coWEEMNnr_SsTCo7HaXUPRwcJg7fUz=NjA8nq@mail.gmail.com>
	<73.C4.59959.876BBEC4@pb1.pair.com>
	<AANLkTikhwbTvpNeW6tufCy=cJzDN3zxaZWtyJPeFEvc=@mail.gmail.com>
	<EBD83EAA-18C4-4F0D-ABE3-C2F8D127FBF3@php.net>
	<3EA67EA2-A9B1-4DFB-8A30-05B37BCA313B@iki.fi>
	<8757232E56758B42B2EE4F9D2CA019C9154B70@US-EX2.zend.net>
	<1290705653.7033.73.camel@guybrush>
	<4CEE9C5F.3040206@lerdorf.com>
	<AANLkTinmQ7a2csTiBPvnZXW_fLbqPNSJm4SzTtZGuBSU@mail.gmail.com>
	<4CEEAA2C.2080308@lerdorf.com>
	<8757232E56758B42B2EE4F9D2CA019C9154E82@US-EX2.zend.net>
	<AANLkTik32p6VsK8TXHNKJjGT3gDsvrviw6cGNeHR5RpE@mail.gmail.com>
	<4CEEB07E.4050004@lerdorf.com>
Date: Thu, 25 Nov 2010 20:01:27 +0100
Message-ID: <AANLkTincoey3F9Uz5F=pwT1xWBR3HwTEBRtb7_-kpKck@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Andi Gutmans <andi@zend.com>, Ilia Alshanetsky <ilia@prohost.org>, 
	=?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>, 
	"davey@php.net" <davey@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: Hold off 5.4
From: pierre.php@gmail.com (Pierre Joye)

On Thu, Nov 25, 2010 at 7:52 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> On 11/25/10 10:43 AM, Pierre Joye wrote:
>> On Thu, Nov 25, 2010 at 7:33 PM, Andi Gutmans <andi@zend.com> wrote:
>>>> -----Original Message-----
>>>> From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
>>>> Sent: Thursday, November 25, 2010 10:26 AM
>>>> To: Ilia Alshanetsky
>>>> Cc: Johannes Schl=FCter; Andi Gutmans; Jani Taskinen; davey@php.net; P=
HP
>>>> Internals
>>>> Subject: Re: [PHP-DEV] Re: Hold off 5.4
>>>>
>>>> We also need that non-null zend_parse_parameters type implemented to c=
lean
>>>> up the null-byte poisoning fixes in 5.3. =A0I can't see this slowing u=
s down much as
>>>> it is pretty trivial. =A0Just takes someone to sit down for a couple o=
f hours and
>>>> implementing it and finding all the places where parameters end up in =
paths.
>>>> There are probably other places we don't want nulls either that curren=
tly have
>>>> local checks that can be removed.
>>>
>>> Yes I agree. We may be able to skip this check for interned strings whi=
ch would be nice and potentially eliminate performance impact somewhat but =
it's something that would need to be looked into. It's non-trivial but doab=
le (need to add a flag for interned strings whether they have a zero byte o=
r not).
>>
>> What do you think about a path argument? Returning something like
>> zend_file_handle with some more meta info. Doing so will let us pass
>> all the way down to the actual file API system call without having to
>> duplicate opearions (stat, perms, etc.) as each ops will simply set
>> the member accordingly.
>
> It wouldn't work in place of the non-null type. =A0There are a number of
> places where we are passing just filenames and it is up to the lower
> level functions to figure out what to do with these and also places
> where we just pass fragments or we pass stuff into things like the
> session extension or database LOB calls. =A0So, even if we did come up
> with a zend_file_handle type, we would still need the non-null type for
> all the places where we don't have a complete path.
>
> Also, I am curious where you think we have duplicate operations like that=
?

I noticed it where functions accepts a path, do some checks (exists,
writable, etc.), resolves paths, etc. and then similar ops are done
again in a couple of places  before we call the low level functions,
like in stream, tsrm for example, or extension using other extension's
streams.

The idea is that file.absolute_path, file.original_path, or
file.resolved_path (example member names) will be passed to the low
level APIs, where each of them have been checked for NULL as well.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org