On Thu, Nov 25, 2010 at 7:52 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > 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?
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
