Re: REMINDER - stream wrappers in include_path

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 <greg@chiaraquartet.net> 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