Hello Pierre,
that sounds like a good idea. Let's provide a generic solution for this.
marcus
Friday, March 28, 2008, 11:03:46 AM, you wrote:
> Hi,
> On Tue, Mar 25, 2008 at 8:01 PM, Gregory Beaver <[EMAIL PROTECTED]> wrote:
>> Stanislav Malyshev wrote:
>> >> stream wrapper. Here is an example:
>> >>
>> >> oops.broken://UNC/path
>> >
>> > I wonder if .://UNC/path is treated as "."+//UNC/path (and the same
>> > for ..). It should anyway :) However I'm not too worried without
>> > pathes like foo.bar - not likely to have path without any slashes
>> > unless it's . or .., and if you do, you always can say ./foo.bar
>> >
>> That's a great question. In attempting to answer, I think I may have
>> unfortunately found a severe flaw in the patch, allowing reading past
>> the end of the filename and the include_path.
>>
>> If we pass a file named "hello:" to php_resolve_path, this code:
>>
>> if ((*p == ':') && (p - filename > 1) && (p[1] == '/') && (p[2] == '/')) {
> A little notice about this test. It is present in many places in our
> code base, it is very difficult to actually fix or improve it without
> introducing side effects on a platform or in a specific case. I
> discussed this test with Dmitry two weeks ago, it would rock to have
> it in a is_url function and manage all specificities there (or in more
> functions in required).
> One case that has to be managed (can be done later) is the Netware
> paths, volumes name can be larger than one later on this platform
> (myvolume: for example). #43353 is a case where the problem occurs.
> I did not test the patch but it would be nice to do this change at the
> same time, it will certainly make our work easier in the future.
> Cheers,
> --
> Pierre
> http://blog.thepimp.net | http://www.libgd.org
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
