Andi Gutmans | 1 Oct 07:58 2004

[PHP-DEV] realpath patch

Hey,

I'd like to commit the realpath() patch I sent to the list for review a 
week or so ago. Unless there are any objections I'll commit it (to HEAD) in 
1-2 days. This will give it some more exposure and will have more people 
testing it.

Andi

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

michael.virnstein | 1 Oct 09:24 2004
Picon

Re-2: [PHP-DEV] Re: declaring classes as static or final


> 
> You mean like an interface adds abstract to all functoins...

exactly. needless to say, that the variable $this would not be available in those classes and that
subclasses of that class have to be static also. what i'm not sure about is, if it would be better to let ppl
type static on the subclass also to not get an error or if the subclass would be static by default without the
static keyword. Probably it would be more readable if they have to use the static keyword on subclasses
too, but as i said, i'm not sure about that.

Regards, Michael

To: helly <at> php.net
Cc: internals <at> lists.php.net

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Leonardo Pedretti | 1 Oct 16:02 2004

Re: [PHP-DEV] [PATCH]Add SO_ORIGINAL_DST support and SOL_IP constant to socket_get_options()

Help needed on this details bob is commenting about the patch (i don't have 
much experience on the configure scripts).
It would be interesting that someone reports the existence/equivalence of the 
SO_ORIGINAL_DST option on some other systems.

Regards
Leo

On Thursday 30 September 2004 17:12, you wrote:
> > This patch adds some quite useful functionalities to socket_get_options()
> > function.
> > ...
> > Things NOT tested: I don't have solaris, bsd, etc. to test it. If someone
> > can test it and report necessary changes, or errors so I can make the
> > changes, It will be appreciated.
>
> At minimum, I would imagine that
>
>   a) changing the autoconf script so that it properly detects if the
>      underlying operating system has support for the capability in question
>      is required;
>
>   b) adding #ifdef/#endif pairs based on the autoconf rewrite to include
>      the proper files on a per-architecture basis.
>
> If you only have Linux, then doing (a) and (b) for the Linux-specific
> case would get your patch a lot farther.  If this patch is applied
> as-is to the PHP sources and then compiled on anything except linux,
> it will break because of #include <linux/...> (at minimum).
>
(Continue reading)

Robert Silva | 1 Oct 16:49 2004

RE: [PHP-DEV] [PATCH]Add SO_ORIGINAL_DST support and SOL_IP constant to socket_get_options()

It looks like this is specific to the Linux kernel getsockopt
implementation.

There may be other ways to do it on different platforms, but SO_ORIGINAL_DST
is not it.

Bob Silva

-----Original Message-----
From: Leonardo Pedretti [mailto:lpedretti <at> suserver.com] 
Sent: Friday, October 01, 2004 7:02 AM
To: internals <at> lists.php.net
Subject: Re: [PHP-DEV] [PATCH]Add SO_ORIGINAL_DST support and SOL_IP
constant to socket_get_options()

Help needed on this details bob is commenting about the patch (i don't have 
much experience on the configure scripts).
It would be interesting that someone reports the existence/equivalence of
the 
SO_ORIGINAL_DST option on some other systems.

Regards
Leo

On Thursday 30 September 2004 17:12, you wrote:
> > This patch adds some quite useful functionalities to
socket_get_options()
> > function.
> > ...
> > Things NOT tested: I don't have solaris, bsd, etc. to test it. If
(Continue reading)

Andi Gutmans | 1 Oct 18:31 2004

[PHP-DEV] Variable fetch optimization

Hi,

Attached is a patch to optimize variable fetches (basically it caches the 
fetches so that variables aren't re-fetched every time, most noticeable in 
loops with the loop control counter but also it's a general improvement).
It's similar to the patch Sterling and Thies did a year ago in their 
optimization patch.
As compiling the zend_execute.c file is starting to take a long time 
(minutes) due to inlining with the goto VM architecture, I suggest to apply 
Zend.m4 to make the default the function handler paradigm. The performance 
difference is not big and it'll make it easier to work on PHP. For 
production environments one can use a configure switch to turn this on.
I'd 
be happy to hear of benchmarks.

In general, there might be problems with extensions which access the active 
symbol table directly. It's something I still need to look into so please 
report any problems.

Please try and take some time to test it.

Andi
--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andi Gutmans | 1 Oct 18:39 2004

Re: [PHP-DEV] Variable fetch optimization

http://snaps.php.net/~andi/Zend.m4.diff.gz
http://snaps.php.net/~andi/cv.diff.gz

At 09:31 AM 10/1/2004 -0700, Andi Gutmans wrote:
>Hi,
>
>Attached is a patch to optimize variable fetches (basically it caches the 
>fetches so that variables aren't re-fetched every time, most noticeable in 
>loops with the loop control counter but also it's a general improvement).
>It's similar to the patch Sterling and Thies did a year ago in their 
>optimization patch.
>As compiling the zend_execute.c file is starting to take a long time 
>(minutes) due to inlining with the goto VM architecture, I suggest to 
>apply Zend.m4 to make the default the function handler paradigm. The 
>performance difference is not big and it'll make it easier to work on PHP. 
>For production environments one can use a configure switch to turn this on.
>I'd be happy to hear of benchmarks.
>
>In general, there might be problems with extensions which access the 
>active symbol table directly. It's something I still need to look into so 
>please report any problems.
>
>Please try and take some time to test it.
>
>Andi
>
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php
(Continue reading)

Sara Golemon | 1 Oct 20:24 2004
Picon
Picon

[PHP-DEV] Re: realpath patch

> I'd like to commit the realpath() patch I sent to the list for review a
> week or so ago. Unless there are any objections I'll commit it (to HEAD)
in
> 1-2 days. This will give it some more exposure and will have more people
> testing it.
>
Somehow the patch is no longer in my news spool, so rather then looking at
the source I'll just ask:  Are all uses of VCWD_REALPATH() effected by this?
If so it could provide a means to bypass basedir checks (and possibly
certain parts of safe_mode).  A scripter on a shared host could create a
symlink, get the cache to catch it, then change the symlink to point to a
different (ordinarily restricted) location, then do normal file ops letting
the basedir check believe that the script is accessing a valid location.

Can we roll in a VCWD_REALPATH_NO_CACHE() macro to avoid problems like this?

-Sara

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Andi Gutmans | 1 Oct 20:34 2004

Re: [PHP-DEV] Re: realpath patch

At 11:24 AM 10/1/2004 -0700, Sara Golemon wrote:
> > I'd like to commit the realpath() patch I sent to the list for review a
> > week or so ago. Unless there are any objections I'll commit it (to HEAD)
>in
> > 1-2 days. This will give it some more exposure and will have more people
> > testing it.
> >
>Somehow the patch is no longer in my news spool, so rather then looking at
>the source I'll just ask:  Are all uses of VCWD_REALPATH() effected by this?
>If so it could provide a means to bypass basedir checks (and possibly
>certain parts of safe_mode).  A scripter on a shared host could create a
>symlink, get the cache to catch it, then change the symlink to point to a
>different (ordinarily restricted) location, then do normal file ops letting
>the basedir check believe that the script is accessing a valid location.
>
>Can we roll in a VCWD_REALPATH_NO_CACHE() macro to avoid problems like this?

http://snaps.php.net/~andi/realpath_cache2.diff

Hmm, you are quite a hacker :)
I think you might be on to something. Can you take a look and see what 
changes we'd require?

Andi

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

(Continue reading)

Robert Silva | 1 Oct 20:49 2004

[PHP-DEV] [PATCH] Small ini file optimization

During php_init_config() in php_ini.c, it currently loads environment
settings, (on windows, system directories and registry settings), binary
locations building the path to search for ini files.

If you specify -n on the command line, any code that would use these paths
are excluded so building the search path is all for not.

This patch saves quite a few system calls on windows and returns immediately
if -n has been specified. As best as I could tell, there would be no side
effects to this immediate return.

The changes are much smaller than the patch file due to some code
reformatting to maintain proper indentation.

Also, I noticed (on my system at least) that my windows directory was
searched 3 times for php.ini (which doesn't exist there). Would a little
caching mechanism for php_fopen_with_path, to not duplicate lookups be worth
it? Could it be designed in such a way that it would be faster than the stat
calls on the filesystem which may make use of disk cache.

Bob Silva

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rasmus Lerdorf | 1 Oct 21:01 2004
Picon
Picon

Re: [PHP-DEV] Re: realpath patch

On Fri, 1 Oct 2004, Andi Gutmans wrote:
> At 11:24 AM 10/1/2004 -0700, Sara Golemon wrote:
> > > I'd like to commit the realpath() patch I sent to the list for review a
> > > week or so ago. Unless there are any objections I'll commit it (to HEAD)
> >in
> > > 1-2 days. This will give it some more exposure and will have more people
> > > testing it.
> > >
> >Somehow the patch is no longer in my news spool, so rather then looking at
> >the source I'll just ask:  Are all uses of VCWD_REALPATH() effected by this?
> >If so it could provide a means to bypass basedir checks (and possibly
> >certain parts of safe_mode).  A scripter on a shared host could create a
> >symlink, get the cache to catch it, then change the symlink to point to a
> >different (ordinarily restricted) location, then do normal file ops letting
> >the basedir check believe that the script is accessing a valid location.
> >
> >Can we roll in a VCWD_REALPATH_NO_CACHE() macro to avoid problems like this?
>
> http://snaps.php.net/~andi/realpath_cache2.diff
>
> Hmm, you are quite a hacker :)
> I think you might be on to something. Can you take a look and see what
> changes we'd require?

The only real way around this is to not cache when safemode is on.  The
whole point of the realpath cache is to assume that the directory
structure on a server doesn't change very often, which is normally the
case.  If someone changes it on purpose underneath it, all bets are off.

On the other hand, if someone has access to make directory structure
(Continue reading)


Gmane