Re: Re: Hold off 5.4

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üter; Andi Gutmans; Jani Taskinen; davey@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