Hi Greg,
I just don't see if my changes broke something.
So could you please prove that committed patch has an issue (with test
case), and restore part of your patch that was going to fix the issue.
Sorry for double work.
Thanks. Dmitry.
Greg Beaver wrote:
Dmitry Stogov wrote:
Hi Marcus,
Dmitry Stogov wrote:
Hi Marcus,
Sorry, if I broke something in latest patch, I just didn't see any
comments from others about it. And from my point of view the patch did
unnecessary things. I still think the same, becaus I mainly changed code
that checks for wrapper in given argument, but not in
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 exa
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 :) H
Hi Marcus,
Sorry, if I broke something in latest patch, I just didn't see any
comments from others about it. And from my point of view the patch did
unnecessary things. I still think the same, becaus I mainly changed code
that checks for wrapper in given argument, but not in include_path.
BTW: I
Hello Dmitry,
Thursday, March 27, 2008, 11:33:55 AM, you wrote:
> Hi Greg,
> in php_resolve_path()
> - you removed (p - filename > 1) check but it means that c://tmp will be
> used as stream wrapper
Basically he doesn't need to. The code with your modifiactions is wrong now.
He changed it t
Hi Greg,
in php_resolve_path()
- you removed (p - filename > 1) check but it means that c://tmp will be
used as stream wrapper
- you added check for !wrapper, but we don't need to do any filesystem
search for filename with wrong wrapper
I've removed this modifications.
I also added proper
Marcus Boerger wrote:
> Hello Gregory,
>
> + for (p = ptr; isalnum((int)*p) || *p == '+' || *p == '-' ||
> *p == '.'; p++);
> + /* p - ptr > 1 allows us to skip things like "C:\whatever" */
> + if ((*p == ':') && (p - ptr > 1) && (path_len - (p - path) >
Hello Gregory,
+ for (p = ptr; isalnum((int)*p) || *p == '+' || *p == '-' || *p
== '.'; p++);
+ /* p - ptr > 1 allows us to skip things like "C:\whatever" */
+ if ((*p == ':') && (p - ptr > 1) && (path_len - (p - path) > 2)
&& (p[1] == '/') && (p[2] == '
Marcus Boerger wrote:
> Hello Gregory,
>
> Tuesday, March 25, 2008, 8:01:56 PM, you 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 anywa
Hello Gregory,
Tuesday, March 25, 2008, 8:01:56 PM, you 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
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 slash
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 d
Dmitry Stogov wrote:
:(
Any ideas how to support this?
Dmitry.
Stefan Walk wrote:
On Monday 24 March 2008 20:28:49 Stanislav Malyshev wrote:
Beats me, I'm sure posix-based systems don't, but it is called "Uniform
Naming Convention" so it's possible somebody might implement it
The fact that i
:(
Any ideas how to support this?
Dmitry.
Stefan Walk wrote:
On Monday 24 March 2008 20:28:49 Stanislav Malyshev wrote:
Beats me, I'm sure posix-based systems don't, but it is called "Uniform
Naming Convention" so it's possible somebody might implement it
The fact that it's called "uniform" d
On Monday 24 March 2008 20:28:49 Stanislav Malyshev wrote:
> > Beats me, I'm sure posix-based systems don't, but it is called "Uniform
> > Naming Convention" so it's possible somebody might implement it
>
> The fact that it's called "uniform" doesn't mean it works in anything
> but Windows :) In UN
I'm going to commit it tomorrow.
Thanks. Dmitry.
Gregory Beaver wrote:
Dmitry Stogov wrote:
I hope it's the last iteration, but check me anyway.
The patch is based on latest Gregory's patch.
- optimized out strncpy() calls
- zend_resolve_path() replaced with php_resolve_path()
- improved php_
Dmitry Stogov wrote:
> I hope it's the last iteration, but check me anyway.
> The patch is based on latest Gregory's patch.
>
> - optimized out strncpy() calls
> - zend_resolve_path() replaced with php_resolve_path()
> - improved php_resolve_path() to resolve "file://..."
> - fixed possible double-
I hope it's the last iteration, but check me anyway.
The patch is based on latest Gregory's patch.
- optimized out strncpy() calls
- zend_resolve_path() replaced with php_resolve_path()
- improved php_resolve_path() to resolve "file://..."
- fixed possible double-free issue in _php_stream_open_wr
Andi Gutmans wrote:
Can we please use strlcpy() instead of strncpy()? This is a coding
standard we implemented years ago.
obviously an easy change. FYI - this also needs to be fixed in
fopen_with_path_rel in PHP_5_2, as I copied most of the code from that
function.
Greg
--
PHP Internals -
; Stas Malyshev
> Subject: Re: [PHP-DEV] REMINDER - stream wrappers in include_path
>
> Hi Greg,
>
> I've fixed your patch to work with all functions (fopen,
> file_get_contente).
> Please verify it with ext/phar and then I'll commit it.
>
> Thanks. Dmitry.
&g
Beats me, I'm sure posix-based systems don't, but it is called "Uniform
Naming Convention" so it's possible somebody might implement it
The fact that it's called "uniform" doesn't mean it works in anything
but Windows :) In UNIX IIRC if one needs to access SMB volume the
regular smb:// URLs ar
Stanislav Malyshev wrote:
>> this would unfortunately break UNC paths on unix, which start with //.
>
> Unix has UNC paths?
Beats me, I'm sure posix-based systems don't, but it is called "Uniform
Naming Convention" so it's possible somebody might implement it
(http://en.wikipedia.org/wiki/Path_(
this would unfortunately break UNC paths on unix, which start with //.
Unix has UNC paths?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
Dmitry Stogov wrote:
>
>
> Gregory Beaver wrote:
>> Dmitry Stogov wrote:
>>> REALPATH_FAILED looks like a hack :(
>>> PHP itself doesn't need it at all, according to your patch
>>> php_stream_open() may just return NULL immediately instead of setting
>>> of this flag.
>>> However I am not sure that
Gregory Beaver wrote:
Dmitry Stogov wrote:
REALPATH_FAILED looks like a hack :(
PHP itself doesn't need it at all, according to your patch
php_stream_open() may just return NULL immediately instead of setting
of this flag.
However I am not sure that it will work for all cases. The fact that
we
Dmitry Stogov wrote:
> REALPATH_FAILED looks like a hack :(
> PHP itself doesn't need it at all, according to your patch
> php_stream_open() may just return NULL immediately instead of setting
> of this flag.
> However I am not sure that it will work for all cases. The fact that
> we cannot resolve
REALPATH_FAILED looks like a hack :(
PHP itself doesn't need it at all, according to your patch
php_stream_open() may just return NULL immediately instead of setting of
this flag.
However I am not sure that it will work for all cases. The fact that we
cannot resolve the path doesn't mean that w
The direct comparison must be faster than memcmp().
memcmp() might be optimized into the same code but probably won't be.
Thanks. Dmitry.
Marcus Boerger wrote:
Hello Gregory,
Monday, March 24, 2008, 2:47:25 PM, you wrote:
Marcus Boerger wrote:
Hello Gregory,
Monday, March 24, 2008, 2:28:00
Hello Gregory,
Monday, March 24, 2008, 2:47:25 PM, you wrote:
> Marcus Boerger wrote:
>> Hello Gregory,
>>
>> Monday, March 24, 2008, 2:28:00 PM, you wrote:
>>
>>
>>> Index: main/fopen_wrappers.c
>>> ===
>>> RCS file: /repository/
Marcus Boerger wrote:
> Hello Gregory,
>
> Monday, March 24, 2008, 2:28:00 PM, you wrote:
>
>
>> Index: main/fopen_wrappers.c
>> ===
>> RCS file: /repository/php-src/main/fopen_wrappers.c,v
>> retrieving revision 1.175.2.3.2.13.2.9
Hello Gregory,
Monday, March 24, 2008, 2:28:00 PM, you wrote:
> Index: main/fopen_wrappers.c
> ===
> RCS file: /repository/php-src/main/fopen_wrappers.c,v
> retrieving revision 1.175.2.3.2.13.2.9
> diff -u -r1.175.2.3.2.13.2.9 fopen_
Dmitry Stogov wrote:
> Hi Greg,
>
> In your second patch you forgot "break", so it couldn't work.
> I don't see any reason in second patch at all, because you call
> php_resolve_patch() from _php_stream_open_wrapper_ex() anyway.
>
> The bad thing with the first part that it calls realpath() functio
Hi Greg,
In your second patch you forgot "break", so it couldn't work.
I don't see any reason in second patch at all, because you call
php_resolve_patch() from _php_stream_open_wrapper_ex() anyway.
The bad thing with the first part that it calls realpath() function
twice for each include("rel
Gregory Beaver wrote:
Dmitry Stogov wrote:
Hi Greg,
I've fixed your patch to work with all functions (fopen,
file_get_contente).
Please verify it with ext/phar and then I'll commit it.
Thanks. Dmitry.
Gregory Beaver wrote:
Hi,
Please look at the stream wrappers in include_path patch I pos
Dmitry Stogov wrote:
> Hi Greg,
>
> I've fixed your patch to work with all functions (fopen,
> file_get_contente).
> Please verify it with ext/phar and then I'll commit it.
>
> Thanks. Dmitry.
>
> Gregory Beaver wrote:
>> Hi,
>>
>> Please look at the stream wrappers in include_path patch I posted
>
Hi Greg,
I've fixed your patch to work with all functions (fopen, file_get_contente).
Please verify it with ext/phar and then I'll commit it.
Thanks. Dmitry.
Gregory Beaver wrote:
Hi,
Please look at the stream wrappers in include_path patch I posted last week.
Thanks,
Greg
Index: main/fopen
Hi Greg,
Please look at the stream wrappers in include_path patch I posted last
week.
I went to try this, but the patch doesn't apply to 5_3 any more since the
re2c change. Could you post an updated version please?
Thanks,
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
T
Hi,
Please look at the stream wrappers in include_path patch I posted last week.
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
39 matches
Mail list logo
