On 11/25/10 10:43 AM, Pierre Joye wrote:
> On Thu, Nov 25, 2010 at 7:33 PM, Andi Gutmans <a...@zend.com> wrote:
>>> -----Original Message-----
>>> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
>>> Sent: Thursday, November 25, 2010 10:26 AM
>>> To: Ilia Alshanetsky
>>> Cc: Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP
>>> Internals
>>> Subject: Re: [PHP-DEV] Re: Hold off 5.4
>>>
>>> We also need that non-null zend_parse_parameters type implemented to clean
>>> up the null-byte poisoning fixes in 5.3.  I can't see this slowing us down 
>>> much as
>>> it is pretty trivial.  Just takes someone to sit down for a couple of 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 currently 
>>> have
>>> local checks that can be removed.
>>
>> Yes I agree. We may be able to skip this check for interned strings which 
>> 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 doable 
>> (need to add a flag for interned strings whether they have a zero byte or 
>> 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.  There 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.  So, 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?

-R

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to