[PHP-DEV] Bug #44872 canary mismatch on efree() - heap overflow detected

[Krister Karlström]

Hi,

This bug #44872 puzzles me, I experienced it today running testcases 
with PHPUnit on command line, thus invoking PHP CLI. I'm working on a 
Ubuntu Hardy 8.0.4 server, using PHP 5.2.4-2ubuntu5.3 with

Suhosin-Patch 0.9.6.2 (cli).

The operation mssql_free_result() is terminated by Suhosin with the 
following message:


ALERT - canary mismatch on efree() - heap overflow detected (attacker
'REMOTE_ADDR not set', file 'TestMsSQL.php', line 16)

The bug report for this matter has status "No feedback". The bug was 
reported on 30 Apr 5:19pm UTC, and status was changed to "no feedback" 
on 10 May 1:00am UTC. However, after that some comments confirming this 
bug have been posted, including myself today.


Does anyone know where's the _source_ of this problem? Is it in the 
source code of PHP or in the Suhosin patch? I have not encountered this 
problem in a "pure" Slackware environment where the Suhosin patch is not 
used, so it seems like a Suhosin issue. It might as well be a bug in PHP 
that Suhosin catches...


Maybe someone should re-open this ticket?
http://bugs.php.net/bug.php?id=44872

Greetings,
Krister Karlström, Helsinki, Finland

--
* Ing. Krister Karlström, Zend Certified Engineer *
* Systemutvecklare, IT-Centralen  *
* Arcada - Nylands Svenska Yrkeshögskola  *
* Jan-Magnus Janssons plats 1, 00550 Helsingfors, Finland *
* Tel: +358(20)7699699  GSM: +358(50)5328390  *
* E-mail: [EMAIL PROTECTED]   *

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

Re: [PHP-DEV] PHP 5.2.7RC1 Testing

[Lester Caine]

Ilia Alshanetsky wrote:
The first release candidate of 5.2.7 was just released for testing and 
can be downloaded here:


http://downloads.php.net/ilia/php-5.2.7RC1.tar.bz2 (md5sum: 
be7544212fe4a3ede775a3793ecd3967)


The Windows binaries should become available shortly as well, for now 
you can grab the win32 snapshots from snaps.php.net. This release has 
been long in coming, so the NEWS file looks quite impressive with an 
extensive number of bug fixes. I do not believe any of the fixes are 
bound to introduce any regression and the hope is to have a final 
release out in the next 2-3 weeks. To make this possible, please test 
this RC against your code base and report any problems that you encounter.


http://snaps.php.net/ is saying that the last Win32 build was on Aug 6 and I'd 
like to get my hands on a more recent build as a couple of the niggles with 
the php_interbase driver have now been flagged as fixed.


I asked earlier in the week what is the correct way to get a driver forked, 
since it is now becoming critical that we have a php_firebird driver built 
against the firebird client rather than the much older compatibility client :(


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

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

Re: [PHP-DEV] Bug #44872 canary mismatch on efree() - heap overflow detected

[Pierre Joye]

hi,

On Fri, Oct 10, 2008 at 1:18 PM, Krister Karlström
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> This bug #44872 puzzles me, I experienced it today running testcases with
> PHPUnit on command line, thus invoking PHP CLI. I'm working on a Ubuntu
> Hardy 8.0.4 server, using PHP 5.2.4-2ubuntu5.3 with
> Suhosin-Patch 0.9.6.2 (cli).

We support only our official releases, not patched versions like
ubuntu, debian or using Suhosin. Have you tried to run your script
(the last small one) using an official version through valgrind?

--
Pierre

http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] php_firebird

[Pierre Joye]

hi Lester,

On Tue, Oct 7, 2008 at 8:18 PM, Lester Caine <[EMAIL PROTECTED]> wrote:
> What is the correct procedure to create a new driver, or rather clone the
> existing php_interbase so that we can build a proper Firebird version that
> actually uses the fbclient.dll rather than sharing the now incompatible
> GDS32.DLL client. Some people are starting to use Interbase in parallel with
> Firebird, but the driver can only access one client :(

I wonder where ended our discussions about fixing firebird/interbase
issues on windows. Despite my reminders, I saw nothing from any of the
volunteers. It is very unlikely that I or any other will take care of
these drivers any time soon. That means that it is likely to do not be
present at all in 5.3.0+ (windows).

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] json_encode ignores protected/private class members

[Richard Quadling]

2008/10/9 Rodrigo Saboya <[EMAIL PROTECTED]>:
> Jarismar Chaves da Silva wrote:
>>
>> I agree with you.
>> But when using json_encode I believe the developer wants to transfer the
>> complete object state, just like when using serialize.
>> Serialize does see private/protected class members, while json_encode not.
>> Javascript does not have class-accessors so why not convert
>> protected/private to public javascript attributes.
>
> In theory only the public members are relevant to anyone except the object
> itself. If you need information about private/protected members you are
> either using the wrong visibility for your variables or using json for
> something it's not supposed to do.
>
> -- Rodrigo Saboya
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

A simply userland solution would be to use an abstract base class with
json_encode()/json_decode() as public final methods. All classes
needing to support json_encode/json_decode would simply need to extend
from this base class.

No need to add even more "magic" to the base stdClass.

Richard.

-- 
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

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

Re: [PHP-DEV] License for Windows binaries

[Hannes Magnusson]

On Fri, Oct 10, 2008 at 05:40, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> Cristian Rodríguez wrote:
>> 田中 裕一 escribió:
>>> Hi all,
>>>
>>> Could anyone tell me the license of the binaries and source code placed 
>>> here?
>>> http://pecl2.php.net/downloads/php-windows-builds/
>>
>> there is no restriction on using PHP in commercial products, as long you
>> comply with PHP license
>
> PHP's license is, as Cristian says, very liberal and you have nothing to
> worry about until you link to something ;-)

I'm pretty sure that was his question: Can he link to these libraries
without issues?

-Hannes

Re: [PHP-DEV] json_encode ignores protected/private class members

[Richard Quadling]

2008/10/10 Jarismar Chaves da Silva <[EMAIL PROTECTED]>:
>
>
> Rodrigo Saboya wrote:
>>
>> Jarismar Chaves da Silva wrote:
>>>
>>> I agree with you.
>>> But when using json_encode I believe the developer wants to transfer the
>>> complete object state, just like when using serialize.
>>> Serialize does see private/protected class members, while json_encode
>>> not.
>>> Javascript does not have class-accessors so why not convert
>>> protected/private to public javascript attributes.
>>
>> In theory only the public members are relevant to anyone except the object
>> itself. If you need information about private/protected members you are
>> either using the wrong visibility for your variables or using json for
>> something it's not supposed to do.
>
> Yes, of course. But currently json_encode ignores the attributes even if the
> call is from inside the class.
>  class Person {
>   protected $name;
>
>   public function __construct($sName) {
>   $this->name = $sName;
>   }
>
>   public function toJSON() {
>   return json_encode($this);
>   }
> }
>
> $person = new Person('jaris');
> print $person->toJSON(); // ==> will print an empty object e.g. {}
> ?>
>
> I don't know if I'm using json_encode for something it's not supposed to do.
> I'm using it to serialize an object to send it to another
> runtime-environment in response to an remote call, just like what I can do
> with SOAP, REST or RMI. In this context I don't see much sense in preventing
> protected/private data from being transfered.
>
> Regards,
> Jaris.
>
>> -- Rodrigo Saboya
>>
>
> --
>
> *Jarismar Chaves da Silva, M.Sc.*
>
> *ADP**Labs** Brazil**
> [EMAIL PROTECTED] 
> http://www.adp.com
>
>

Let's just for example say that class X has the username and password
values for the login system.

You've made them private as only this class should access them.

How are you going to stop the json_encode() from seeing them and
passing them on.




-- 
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

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

Re: [PHP-DEV] php_firebird

[marius popa]

On Fri, Oct 10, 2008 at 3:50 PM, Pierre Joye <[EMAIL PROTECTED]> wrote:
> hi Lester,
>
> On Tue, Oct 7, 2008 at 8:18 PM, Lester Caine <[EMAIL PROTECTED]> wrote:
>> What is the correct procedure to create a new driver, or rather clone the
>> existing php_interbase so that we can build a proper Firebird version that
>> actually uses the fbclient.dll rather than sharing the now incompatible
>> GDS32.DLL client. Some people are starting to use Interbase in parallel with
>> Firebird, but the driver can only access one client :(
>
> I wonder where ended our discussions about fixing firebird/interbase
> issues on windows. Despite my reminders, I saw nothing from any of the
> volunteers. It is very unlikely that I or any other will take care of
> these drivers any time soon. That means that it is likely to do not be
> present at all in 5.3.0+ (windows).
I don't have any windows machine , do php group have one to share ? or
where do you build these things ?
I will try to setup an virtual machine with windows and all the rest
The only problem is now I'm looking for an job and i need to find an
job first :(

>
> Cheers,
> --
> Pierre
> http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
developer flamerobin.org

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

Re: [PHP-DEV] License for Windows binaries

[Ulf Wendel]

William A. Rowe, Jr. schrieb:

Well, the binaries probably include c runtimes under liberal MS license.
They might be kind and give you mysql and a host of other GPL features under
a very restrictive license.


With any PHP before 5.3, you'll have to compile any of the MySQL 
extensions (ext/mysqli, PDO MySQL, ext/mysql) against the MySQL Client 
Library (libmysql). libmysql is GPL + FLOSS Licence exception [1].


As of PHP 5.3 you can optionally compile all the MySQL extensions 
against the MySQL native driver for PHP (mysqlnd) instead of compiling 
against libmysqlnd. mysqlnd is part of the PHP source tree and as such 
licensed under the terms of the PHP license.



PHP's license is, as Cristian says, very liberal and you have nothing to
worry about until you link to something ;-)


Go PHP 5.3, go mysqlnd ;-)

Ulf

[1] http://www.mysql.com/about/legal/licensing/foss-exception.html


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

Re: [PHP-DEV] json_encode ignores protected/private class members

[Jarismar Chaves da Silva]

Rodrigo Saboya wrote:

Jarismar Chaves da Silva wrote:

I agree with you.
But when using json_encode I believe the developer wants to transfer 
the complete object state, just like when using serialize.
Serialize does see private/protected class members, while json_encode 
not.
Javascript does not have class-accessors so why not convert 
protected/private to public javascript attributes.


In theory only the public members are relevant to anyone except the 
object itself. If you need information about private/protected members 
you are either using the wrong visibility for your variables or using 
json for something it's not supposed to do.


Yes, of course. But currently json_encode ignores the attributes even if 
the call is from inside the class.

name = $sName;
   }

   public function toJSON() {
   return json_encode($this);
   }
}

$person = new Person('jaris');
print $person->toJSON(); // ==> will print an empty object e.g. {}
?>

I don't know if I'm using json_encode for something it's not supposed to 
do. I'm using it to serialize an object to send it to another 
runtime-environment in response to an remote call, just like what I can 
do with SOAP, REST or RMI. In this context I don't see much sense in 
preventing protected/private data from being transfered.


Regards,
Jaris.


-- Rodrigo Saboya



--

*Jarismar Chaves da Silva, M.Sc.*

*ADP**Labs** Brazil**
[EMAIL PROTECTED] 
http://www.adp.com 

Re: [PHP-DEV] License for Windows binaries

[Pierre Joye]

hi Yuichi,

On Fri, Oct 10, 2008 at 4:25 AM, 田中 裕一 <[EMAIL PROTECTED]> wrote:

> Could anyone tell me the license of the binaries and source code placed here?
> http://pecl2.php.net/downloads/php-windows-builds/
>
> I am developing a commercial package software using PHP and I will build
> libraries and PHP my own.
> Is it ok to use Visual Studio project files in these zip files 
> (http://pecl2.php.net/downloads/php-windows-builds/source/)
> or these binaries 
> (http://pecl2.php.net/downloads/php-windows-builds/php-libs/)
> for our commercial product and distribute our product with those binaries?

PHP itself is covered by the PHP License (with some portions under
LGPL or BSD). The libraries we provide there are under various
licenses, a link to each library project page is available here:

http://wiki.php.net/internals/windows/libs

We distribute only libraries with a permissive enough license.
However, some of them requires a bit more attention, for example a
notice in some visible place (end user documentation for example)
saying that your software uses their libraries is sometimes required.
That's not a problem for us as we say it anyway in the PHP manual.


Cheers,
-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] Bug #44872 canary mismatch on efree() - heap overflow detected

[Ilia Alshanetsky]

The error messages comes from Suhosin, which is why a basic PHP  
environment does not exhibit this problem. What I can ask you to try  
is to run the affected code on a basic PHP environment through  
valgrind and see if it reports any errors. If it does not, there is a  
chance it maybe a false positive on the part of Suhosin. If it does  
report a problem however, then mssql extension has a bug and valgrind  
output should be good enough to identify the where & the why.



On 10-Oct-08, at 7:18 AM, Krister Karlström wrote:


Hi,

This bug #44872 puzzles me, I experienced it today running testcases  
with PHPUnit on command line, thus invoking PHP CLI. I'm working on  
a Ubuntu Hardy 8.0.4 server, using PHP 5.2.4-2ubuntu5.3 with

Suhosin-Patch 0.9.6.2 (cli).

The operation mssql_free_result() is terminated by Suhosin with the  
following message:


ALERT - canary mismatch on efree() - heap overflow detected (attacker
'REMOTE_ADDR not set', file 'TestMsSQL.php', line 16)

The bug report for this matter has status "No feedback". The bug was  
reported on 30 Apr 5:19pm UTC, and status was changed to "no  
feedback" on 10 May 1:00am UTC. However, after that some comments  
confirming this bug have been posted, including myself today.


Does anyone know where's the _source_ of this problem? Is it in the  
source code of PHP or in the Suhosin patch? I have not encountered  
this problem in a "pure" Slackware environment where the Suhosin  
patch is not used, so it seems like a Suhosin issue. It might as  
well be a bug in PHP that Suhosin catches...


Maybe someone should re-open this ticket?
http://bugs.php.net/bug.php?id=44872

Greetings,
Krister Karlström, Helsinki, Finland

--
* Ing. Krister Karlström, Zend Certified Engineer *
* Systemutvecklare, IT-Centralen  *
* Arcada - Nylands Svenska Yrkeshögskola  *
* Jan-Magnus Janssons plats 1, 00550 Helsingfors, Finland *
* Tel: +358(20)7699699  GSM: +358(50)5328390  *
* E-mail: [EMAIL PROTECTED]   *

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



Ilia Alshanetsky





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

Re: [PHP-DEV] php_firebird

[marius popa]

On Fri, Oct 10, 2008 at 3:50 PM, Pierre Joye <[EMAIL PROTECTED]> wrote:
> hi Lester,
>
> On Tue, Oct 7, 2008 at 8:18 PM, Lester Caine <[EMAIL PROTECTED]> wrote:
>> What is the correct procedure to create a new driver, or rather clone the
>> existing php_interbase so that we can build a proper Firebird version that
>> actually uses the fbclient.dll rather than sharing the now incompatible
>> GDS32.DLL client. Some people are starting to use Interbase in parallel with
>> Firebird, but the driver can only access one client :(
>
> I wonder where ended our discussions about fixing firebird/interbase
> issues on windows. Despite my reminders, I saw nothing from any of the
> volunteers. It is very unlikely that I or any other will take care of
> these drivers any time soon. That means that it is likely to do not be
> present at all in 5.3.0+ (windows).

The only bugs left are the one with blobs
http://bugs.php.net/search.php?cmd=display&status=Open&bug_type%5B%5D=InterBase+related

and i think the failed events tests from the extension directory

Please tell us what issues are still present on windows ?
I guess if you are on an windows machine is quite easy to install firebird
do an full build and send us the report

>
> Cheers,
> --
> Pierre
> http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
developer flamerobin.org

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

Re: [PHP-DEV] PHP 5.2.7RC1 Testing

[Ilia Alshanetsky]

Tim,

The issue has not been looked at further, the issue with charsets is  
pretty close to what you've described in the quoted e-mail.  
Unfortunately, I do not see a fix at this time that would retain the  
security measures and retain BC.



On 9-Oct-08, at 11:48 PM, Tim Starling wrote:


Sorry for the duplicate, Ilia, forgot to copy to list.

Ilia Alshanetsky wrote:
The first release candidate of 5.2.7 was just released for testing  
and

can be downloaded here:


You still haven't fixed the LC_CTYPE issue, have you?

http://marc.info/?l=php-internals&m=121813076018214&w=2

You should see the size of the workaround I had to put in MediaWiki  
for

this bug.

http://svn.wikimedia.org/viewvc/mediawiki/?view=rev&revision=41379

-- Tim Starling



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



Ilia Alshanetsky





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

Re: [PHP-DEV] Bug #44872 canary mismatch on efree() - heap overflow detected

[Krister Karlström]

Hi,

Yes, I do understand that you only support official versions of PHP and 
I totally agree with you.


No, I haven't tried to catch the error using valgrind yet. I just wanted 
to raise the question, since I'm not really sure whether this is a 
problem caused by the Suhosin patch or if it's indeed a memory problem 
somewhere in PHP which is discovered by Suhosin. Or does Suhosin 
"detect" such things?


Anyway, we shouldn't be using Suhosin in first place (it's installed 
only on one webserver), so I'm gonna throw this patched package out and 
replace it with a pure PHP environment... :)


/Krister Karlström

Pierre Joye wrote:


hi,

On Fri, Oct 10, 2008 at 1:18 PM, Krister Karlström
<[EMAIL PROTECTED]> wrote:

Hi,

This bug #44872 puzzles me, I experienced it today running testcases with
PHPUnit on command line, thus invoking PHP CLI. I'm working on a Ubuntu
Hardy 8.0.4 server, using PHP 5.2.4-2ubuntu5.3 with
Suhosin-Patch 0.9.6.2 (cli).


We support only our official releases, not patched versions like
ubuntu, debian or using Suhosin. Have you tried to run your script
(the last small one) using an official version through valgrind?

--
Pierre

http://blog.thepimp.net | http://www.libgd.org


--
* Ing. Krister Karlström, Zend Certified Engineer *
* Systemutvecklare, IT-Centralen  *
* Arcada - Nylands Svenska Yrkeshögskola  *
* Jan-Magnus Janssons plats 1, 00550 Helsingfors, Finland *
* Tel: +358(20)7699699  GSM: +358(50)5328390  *
* E-mail: [EMAIL PROTECTED]   *

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

Re: [PHP-DEV] Bug #44872 canary mismatch on efree() - heap overflow detected

[Krister Karlström]

OK, thanks Ilia!

I'm gonna try the valgrind. Will report back later.

/Krister Karlström

Ilia Alshanetsky wrote:

The error messages comes from Suhosin, which is why a basic PHP 
environment does not exhibit this problem. What I can ask you to try is 
to run the affected code on a basic PHP environment through valgrind and 
see if it reports any errors. If it does not, there is a chance it maybe 
a false positive on the part of Suhosin. If it does report a problem 
however, then mssql extension has a bug and valgrind output should be 
good enough to identify the where & the why.



On 10-Oct-08, at 7:18 AM, Krister Karlström wrote:


Hi,

This bug #44872 puzzles me, I experienced it today running testcases 
with PHPUnit on command line, thus invoking PHP CLI. I'm working on a 
Ubuntu Hardy 8.0.4 server, using PHP 5.2.4-2ubuntu5.3 with

Suhosin-Patch 0.9.6.2 (cli).

The operation mssql_free_result() is terminated by Suhosin with the 
following message:


ALERT - canary mismatch on efree() - heap overflow detected (attacker
'REMOTE_ADDR not set', file 'TestMsSQL.php', line 16)

The bug report for this matter has status "No feedback". The bug was 
reported on 30 Apr 5:19pm UTC, and status was changed to "no feedback" 
on 10 May 1:00am UTC. However, after that some comments confirming 
this bug have been posted, including myself today.


Does anyone know where's the _source_ of this problem? Is it in the 
source code of PHP or in the Suhosin patch? I have not encountered 
this problem in a "pure" Slackware environment where the Suhosin patch 
is not used, so it seems like a Suhosin issue. It might as well be a 
bug in PHP that Suhosin catches...


Maybe someone should re-open this ticket?
http://bugs.php.net/bug.php?id=44872

Greetings,
Krister Karlström, Helsinki, Finland

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



Ilia Alshanetsky


--
* Ing. Krister Karlström, Zend Certified Engineer *
* Systemutvecklare, IT-Centralen  *
* Arcada - Nylands Svenska Yrkeshögskola  *
* Jan-Magnus Janssons plats 1, 00550 Helsingfors, Finland *
* Tel: +358(20)7699699  GSM: +358(50)5328390  *
* E-mail: [EMAIL PROTECTED]   *

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

Re: [PHP-DEV] Bug #44872 canary mismatch on efree() - heap overflow detected

[Stefan Esser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

> a false positive on the part of Suhosin. If it does report a problem
> however, then mssql extension has a bug and valgrind output should be
> good enough to identify the where & the why.

valgrind cannot (by definition) see all memory problems Suhosin detects.

Stefan Esser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjvbr4ACgkQSuF5XhWr2ngkKQCgniliTOQKjqpOJMS30lN2+Vf5
+NMAmgP3FtFlZnmoctZhAI67rDSDqdOI
=M9h8
-END PGP SIGNATURE-

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

Re: [PHP-DEV] Bug #44872 canary mismatch on efree() - heap overflow detected

[Pierre Joye]

hi,

On Fri, Oct 10, 2008 at 5:03 PM, Stefan Esser
<[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
>> a false positive on the part of Suhosin. If it does report a problem
>> however, then mssql extension has a bug and valgrind output should be
>> good enough to identify the where & the why.
>
> valgrind cannot (by definition) see all memory problems Suhosin detects.

It can detect some memory issues and that's what we are asking to try.
If it fails, we will investigate further, obviously :)

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] php_firebird

[Pierre Joye]

On Fri, Oct 10, 2008 at 4:54 PM, marius popa <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 10, 2008 at 3:50 PM, Pierre Joye <[EMAIL PROTECTED]> wrote:
>> hi Lester,
>>
>> On Tue, Oct 7, 2008 at 8:18 PM, Lester Caine <[EMAIL PROTECTED]> wrote:
>>> What is the correct procedure to create a new driver, or rather clone the
>>> existing php_interbase so that we can build a proper Firebird version that
>>> actually uses the fbclient.dll rather than sharing the now incompatible
>>> GDS32.DLL client. Some people are starting to use Interbase in parallel with
>>> Firebird, but the driver can only access one client :(
>>
>> I wonder where ended our discussions about fixing firebird/interbase
>> issues on windows. Despite my reminders, I saw nothing from any of the
>> volunteers. It is very unlikely that I or any other will take care of
>> these drivers any time soon. That means that it is likely to do not be
>> present at all in 5.3.0+ (windows).
>
> The only bugs left are the one with blobs
> http://bugs.php.net/search.php?cmd=display&status=Open&bug_type%5B%5D=InterBase+related
>
> and i think the failed events tests from the extension directory
>
> Please tell us what issues are still present on windows ?

No build are done and none are planed in a near future without a
significant effort from the actual users or developers of the
firebird/interbase drivers.

Cheers,
-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] Bug #44872 canary mismatch on efree() - heap overflow detected

[Krister Karlström]

Hi!

I re-run the small simple script that I posted on the bug tracking page. 
This time I used a Slackware server with PHP 5.2.5 (no Suhosin or other 
patches), compiled from source. php -v gives:


PHP 5.2.5 (cli) (built: Mar 28 2008 12:02:55)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

This is the summary of the run:

==3182== ERROR SUMMARY: 159 errors from 10 contexts (suppressed: 0 from 0)
==3182== malloc/free: in use at exit: 3,174 bytes in 23 blocks.
==3182== malloc/free: 44,130 allocs, 44,107 frees, 3,189,161 bytes 
allocated.

==3182== For counts of detected errors, rerun with: -v
==3182== searching for pointers to 23 not-freed blocks.
==3182== checked 541,584 bytes.
==3182==
==3182== LEAK SUMMARY:
==3182==definitely lost: 853 bytes in 12 blocks.
==3182==  possibly lost: 0 bytes in 0 blocks.
==3182==still reachable: 2,321 bytes in 11 blocks.
==3182== suppressed: 0 bytes in 0 blocks.
==3182== Rerun with --leak-check=full to see details of leaked memory.

I need some help with analyzing the full output, so if it's OK for you 
Ilia I will mail you the full output from valgrind.


/Krister Karlström

Ilia Alshanetsky wrote:

The error messages comes from Suhosin, which is why a basic PHP 
environment does not exhibit this problem. What I can ask you to try is 
to run the affected code on a basic PHP environment through valgrind and 
see if it reports any errors. If it does not, there is a chance it maybe 
a false positive on the part of Suhosin. If it does report a problem 
however, then mssql extension has a bug and valgrind output should be 
good enough to identify the where & the why.



On 10-Oct-08, at 7:18 AM, Krister Karlström wrote:


Hi,

This bug #44872 puzzles me, I experienced it today running testcases 
with PHPUnit on command line, thus invoking PHP CLI. I'm working on a 
Ubuntu Hardy 8.0.4 server, using PHP 5.2.4-2ubuntu5.3 with

Suhosin-Patch 0.9.6.2 (cli).

The operation mssql_free_result() is terminated by Suhosin with the 
following message:


ALERT - canary mismatch on efree() - heap overflow detected (attacker
'REMOTE_ADDR not set', file 'TestMsSQL.php', line 16)

The bug report for this matter has status "No feedback". The bug was 
reported on 30 Apr 5:19pm UTC, and status was changed to "no feedback" 
on 10 May 1:00am UTC. However, after that some comments confirming 
this bug have been posted, including myself today.


Does anyone know where's the _source_ of this problem? Is it in the 
source code of PHP or in the Suhosin patch? I have not encountered 
this problem in a "pure" Slackware environment where the Suhosin patch 
is not used, so it seems like a Suhosin issue. It might as well be a 
bug in PHP that Suhosin catches...


Maybe someone should re-open this ticket?
http://bugs.php.net/bug.php?id=44872

Greetings,
Krister Karlström, Helsinki, Finland

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



Ilia Alshanetsky



--
* Ing. Krister Karlström, Zend Certified Engineer *
* Systemutvecklare, IT-Centralen  *
* Arcada - Nylands Svenska Yrkeshögskola  *
* Jan-Magnus Janssons plats 1, 00550 Helsingfors, Finland *
* Tel: +358(20)7699699  GSM: +358(50)5328390  *
* E-mail: [EMAIL PROTECTED]   *

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

Re: [PHP-DEV] namespaces and alpha3

[Geoffrey Sneddon]

On 10 Oct 2008, at 06:03, Lukas Kahwe Smith wrote:


1) rip them out


I'm +1 on this. We simply don't have consensus, and I don't see anyway  
we can have consensus by the time 5.3 has to be frozen. Once  
namespaces are in, we're gonna have to stick with whatever we choose,  
unless we totally break BC.



--
Geoffrey Sneddon



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

Re: [PHP-DEV] namespaces and alpha3

[Stanislav Malyshev]

Hi!


3) Stas proposal


I have two proposals, actually.

1. Leave functions (and constant) alone, i.e. namespace would ignore that.
1.1 Option: if you define function inside namespace, compiler could give 
an error (I don't like this option, but I mention it for the sake of 
completeness).


2. Leave functions/constants as they are now, and add the following syntax:
Class::Name->method()
for calling static methods (and referring to class constants), so that 
there would be a way to disambiguate calls in (rare, IMHO) situations 
where ambiguity may arise.


--
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: http://www.php.net/unsub.php

[PHP-DEV] segfault after an "invalid read of size 8"

[Olivier Bonvalet]

Hello,

I have a script which throw a segfault, in cli with PHP 5.2.6 (I just 
recompiled it from source).


I track the error with valgrind, and obtain this as a result :
==17069== Invalid read of size 8
==17069==at 0x6CBCAC: _zend_mm_alloc_int (zend_alloc.c:1767)
==17069==by 0x6CC1DF: _estrndup (zend_alloc.c:2422)
==17069==by 0x6EFFDC: add_assoc_string_ex (zend_API.c:1038)
==17069==by 0x567027: zif_posix_uname (posix.c:466)
==17069==by 0x71E3AC: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:200)

==17069==by 0x709983: execute (zend_vm_execute.h:92)
==17069==by 0x6DA134: zend_call_function (zend_execute_API.c:1013)
==17069==by 0x6DB1C5: call_user_function_ex (zend_execute_API.c:640)
==17069==by 0x6DB241: call_user_function (zend_execute_API.c:613)
==17069==by 0x627D1A: user_shutdown_function_call 
(basic_functions.c:5311)

==17069==by 0x6F133A: zend_hash_apply (zend_hash.c:673)
==17069==by 0x627FD5: php_call_shutdown_functions 
(basic_functions.c:5395)

==17069==  Address 0x61 is not stack'd, malloc'd or (recently) free'd
==17069==
==17069== Process terminating with default action of signal 11 (SIGSEGV)
==17069==  Access not within mapped region at address 0x61
==17069==at 0x6CBCAC: _zend_mm_alloc_int (zend_alloc.c:1767)
==17069==by 0x6CC1DF: _estrndup (zend_alloc.c:2422)
==17069==by 0x6EFFDC: add_assoc_string_ex (zend_API.c:1038)
==17069==by 0x567027: zif_posix_uname (posix.c:466)
==17069==by 0x71E3AC: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:200)

==17069==by 0x709983: execute (zend_vm_execute.h:92)
==17069==by 0x6DA134: zend_call_function (zend_execute_API.c:1013)
==17069==by 0x6DB1C5: call_user_function_ex (zend_execute_API.c:640)
==17069==by 0x6DB241: call_user_function (zend_execute_API.c:613)
==17069==by 0x627D1A: user_shutdown_function_call 
(basic_functions.c:5311)

==17069==by 0x6F133A: zend_hash_apply (zend_hash.c:673)
==17069==by 0x627FD5: php_call_shutdown_functions 
(basic_functions.c:5395)

==17069==
==17069== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 66 from 4)
==17069== malloc/free: in use at exit: 2,641,381 bytes in 12,114 blocks.
==17069== malloc/free: 13,138 allocs, 1,024 frees, 7,178,514 bytes 
allocated.

==17069== For counts of detected errors, rerun with: -v
==17069== searching for pointers to 12,114 not-freed blocks.
==17069== checked 2,442,920 bytes.
==17069==
==17069== LEAK SUMMARY:
==17069==definitely lost: 292 bytes in 11 blocks.
==17069==  possibly lost: 0 bytes in 0 blocks.
==17069==still reachable: 2,641,089 bytes in 12,103 blocks.
==17069== suppressed: 0 bytes in 0 blocks.
==17069== Rerun with --leak-check=full to see details of leaked memory.

Should I try to reduce the size of the PHP script (actually it use a 
framework) to can reproduce the problem ; or is this output of valgrind 
is enough ?


Thanks,
Olivier

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

Re: [PHP-DEV] segfault after an "invalid read of size 8"

[Felipe Pena]

Em Sex, 2008-10-10 às 18:58 +0200, Olivier Bonvalet escreveu:
> Hello,
> 
> I have a script which throw a segfault, in cli with PHP 5.2.6 (I just 
> recompiled it from source).
> 
> I track the error with valgrind, and obtain this as a result :
> ==17069== Invalid read of size 8
> ==17069==at 0x6CBCAC: _zend_mm_alloc_int (zend_alloc.c:1767)
> ==17069==by 0x6CC1DF: _estrndup (zend_alloc.c:2422)
> ==17069==by 0x6EFFDC: add_assoc_string_ex (zend_API.c:1038)
> ==17069==by 0x567027: zif_posix_uname (posix.c:466)
> ==17069==by 0x71E3AC: zend_do_fcall_common_helper_SPEC 
> (zend_vm_execute.h:200)
> ==17069==by 0x709983: execute (zend_vm_execute.h:92)
> ==17069==by 0x6DA134: zend_call_function (zend_execute_API.c:1013)
> ==17069==by 0x6DB1C5: call_user_function_ex (zend_execute_API.c:640)
> ==17069==by 0x6DB241: call_user_function (zend_execute_API.c:613)
> ==17069==by 0x627D1A: user_shutdown_function_call 
> (basic_functions.c:5311)
> ==17069==by 0x6F133A: zend_hash_apply (zend_hash.c:673)
> ==17069==by 0x627FD5: php_call_shutdown_functions 
> (basic_functions.c:5395)
> ==17069==  Address 0x61 is not stack'd, malloc'd or (recently) free'd
> ==17069==
> ==17069== Process terminating with default action of signal 11 (SIGSEGV)
> ==17069==  Access not within mapped region at address 0x61
> ==17069==at 0x6CBCAC: _zend_mm_alloc_int (zend_alloc.c:1767)
> ==17069==by 0x6CC1DF: _estrndup (zend_alloc.c:2422)
> ==17069==by 0x6EFFDC: add_assoc_string_ex (zend_API.c:1038)
> ==17069==by 0x567027: zif_posix_uname (posix.c:466)
> ==17069==by 0x71E3AC: zend_do_fcall_common_helper_SPEC 
> (zend_vm_execute.h:200)
> ==17069==by 0x709983: execute (zend_vm_execute.h:92)
> ==17069==by 0x6DA134: zend_call_function (zend_execute_API.c:1013)
> ==17069==by 0x6DB1C5: call_user_function_ex (zend_execute_API.c:640)
> ==17069==by 0x6DB241: call_user_function (zend_execute_API.c:613)
> ==17069==by 0x627D1A: user_shutdown_function_call 
> (basic_functions.c:5311)
> ==17069==by 0x6F133A: zend_hash_apply (zend_hash.c:673)
> ==17069==by 0x627FD5: php_call_shutdown_functions 
> (basic_functions.c:5395)
> ==17069==
> ==17069== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 66 from 4)
> ==17069== malloc/free: in use at exit: 2,641,381 bytes in 12,114 blocks.
> ==17069== malloc/free: 13,138 allocs, 1,024 frees, 7,178,514 bytes 
> allocated.
> ==17069== For counts of detected errors, rerun with: -v
> ==17069== searching for pointers to 12,114 not-freed blocks.
> ==17069== checked 2,442,920 bytes.
> ==17069==
> ==17069== LEAK SUMMARY:
> ==17069==definitely lost: 292 bytes in 11 blocks.
> ==17069==  possibly lost: 0 bytes in 0 blocks.
> ==17069==still reachable: 2,641,089 bytes in 12,103 blocks.
> ==17069== suppressed: 0 bytes in 0 blocks.
> ==17069== Rerun with --leak-check=full to see details of leaked memory.
> 
> Should I try to reduce the size of the PHP script (actually it use a 
> framework) to can reproduce the problem ; or is this output of valgrind 
> is enough ?
> 

Please try using this CVS snapshot:
  http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip): 
  http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi

In case of segfaulting with the latest version, file a bug at
http://bugs.php.net

Thanks. :)

-- 
Regards,
Felipe Pena


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

Re: [PHP-DEV] segfault after an "invalid read of size 8"

[Olivier Bonvalet]

Thanks, with this version I obtain this valgrind output :

==6577== Conditional jump or move depends on uninitialised value(s)
==6577==at 0x6CB2DB: _zend_mm_free_int (zend_alloc.c:1941)
==6577==by 0x710210: ZEND_CONCAT_SPEC_CV_TMP_HANDLER 
(zend_variables.h:35)

==6577==by 0x709D63: execute (zend_vm_execute.h:92)
==6577==by 0x6DA33C: zend_call_function (zend_execute_API.c:1015)
==6577==by 0x6DB3C5: call_user_function_ex (zend_execute_API.c:640)
==6577==by 0x6DB441: call_user_function (zend_execute_API.c:613)
==6577==by 0x627DAA: user_shutdown_function_call 
(basic_functions.c:5311)

==6577==by 0x6F158A: zend_hash_apply (zend_hash.c:673)
==6577==by 0x628065: php_call_shutdown_functions 
(basic_functions.c:5395)

==6577==by 0x6A2B44: php_request_shutdown (main.c:1446)
==6577==by 0x75B0B3: main (php_cli.c:1315)
==6577==
==6577== Use of uninitialised value of size 8
==6577==at 0x6CB33A: _zend_mm_free_int (zend_alloc.c:1963)
==6577==by 0x710210: ZEND_CONCAT_SPEC_CV_TMP_HANDLER 
(zend_variables.h:35)

==6577==by 0x709D63: execute (zend_vm_execute.h:92)
==6577==by 0x6DA33C: zend_call_function (zend_execute_API.c:1015)
==6577==by 0x6DB3C5: call_user_function_ex (zend_execute_API.c:640)
==6577==by 0x6DB441: call_user_function (zend_execute_API.c:613)
==6577==by 0x627DAA: user_shutdown_function_call 
(basic_functions.c:5311)

==6577==by 0x6F158A: zend_hash_apply (zend_hash.c:673)
==6577==by 0x628065: php_call_shutdown_functions 
(basic_functions.c:5395)

==6577==by 0x6A2B44: php_request_shutdown (main.c:1446)
==6577==by 0x75B0B3: main (php_cli.c:1315)
==6577==
==6577== Invalid read of size 1
==6577==at 0x6CB33A: _zend_mm_free_int (zend_alloc.c:1963)
==6577==by 0x710210: ZEND_CONCAT_SPEC_CV_TMP_HANDLER 
(zend_variables.h:35)

==6577==by 0x709D63: execute (zend_vm_execute.h:92)
==6577==by 0x6DA33C: zend_call_function (zend_execute_API.c:1015)
==6577==by 0x6DB3C5: call_user_function_ex (zend_execute_API.c:640)
==6577==by 0x6DB441: call_user_function (zend_execute_API.c:613)
==6577==by 0x627DAA: user_shutdown_function_call 
(basic_functions.c:5311)

==6577==by 0x6F158A: zend_hash_apply (zend_hash.c:673)
==6577==by 0x628065: php_call_shutdown_functions 
(basic_functions.c:5395)

==6577==by 0x6A2B44: php_request_shutdown (main.c:1446)
==6577==by 0x75B0B3: main (php_cli.c:1315)
==6577==  Address 0x706eda800 is not stack'd, malloc'd or (recently) free'd
==6577==
==6577== Process terminating with default action of signal 11 (SIGSEGV)
==6577==  Access not within mapped region at address 0x706EDA800
==6577==at 0x6CB33A: _zend_mm_free_int (zend_alloc.c:1963)
==6577==by 0x710210: ZEND_CONCAT_SPEC_CV_TMP_HANDLER 
(zend_variables.h:35)

==6577==by 0x709D63: execute (zend_vm_execute.h:92)
==6577==by 0x6DA33C: zend_call_function (zend_execute_API.c:1015)
==6577==by 0x6DB3C5: call_user_function_ex (zend_execute_API.c:640)
==6577==by 0x6DB441: call_user_function (zend_execute_API.c:613)
==6577==by 0x627DAA: user_shutdown_function_call 
(basic_functions.c:5311)

==6577==by 0x6F158A: zend_hash_apply (zend_hash.c:673)
==6577==by 0x628065: php_call_shutdown_functions 
(basic_functions.c:5395)

==6577==by 0x6A2B44: php_request_shutdown (main.c:1446)
==6577==by 0x75B0B3: main (php_cli.c:1315)
==6577==
==6577== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 66 from 4)
==6577== malloc/free: in use at exit: 2,641,381 bytes in 12,114 blocks.
==6577== malloc/free: 13,138 allocs, 1,024 frees, 7,178,513 bytes allocated.
==6577== For counts of detected errors, rerun with: -v
==6577== searching for pointers to 12,114 not-freed blocks.
==6577== checked 2,441,216 bytes.
==6577==
==6577== LEAK SUMMARY:
==6577==definitely lost: 292 bytes in 11 blocks.
==6577==  possibly lost: 0 bytes in 0 blocks.
==6577==still reachable: 2,641,089 bytes in 12,103 blocks.
==6577== suppressed: 0 bytes in 0 blocks.
==6577== Rerun with --leak-check=full to see details of leaked memory.


Felipe Pena a écrit :

Please try using this CVS snapshot:
  http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip): 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

For Windows (installer):
  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi

In case of segfaulting with the latest version, file a bug at
http://bugs.php.net

Thanks. :)

  



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

Re: [PHP-DEV] __getStatic

[Stanislav Malyshev]

Hi!


I've updated the patch and added some tests with it.

http://sitten-polizei.de/php/getstatic.diff


Looked at the patch. There's some things I noticed there:
1. _getstatic->common.fn_flags |= ~ZEND_ACC_ALLOW_STATIC;
What was the idea here? Maybe ~ is not intended?

2. Do we really need ZEND_ASSIGN_CLASS opcode, can't we reuse ASSIGN_OBJ 
with flag, as we do for fetches?


3. In zend_std_set_static_property, I'm not sure we need to do 
zend_update_class_constants there. We won't be using any values from it.


4. In zend_std_set_static_property, why you create new property_info two 
times when property does not exist?


5. In zend_std_set_static_property, old value of the property is not 
destroyed. Also, I'm not sure separation is handled there correctly - 
previous value may be shared between variables, and just replacing it 
would affect all shared variables. You may see how property handler does 
assignments.
Alternatively, in the absence of the setter, you may just use the 
existing assignment handler, just fetching the zval** as before and 
passing it to zend_assign_to_variable. This would probably be better - 
less stuff to do.


6. What would happen with foo::$bar += 1? I don't see assign-ops handled 
anywhere in the patch.


7. Does zend_std_get_static_property handle the case of return by-ref 
like property one does?

--
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: http://www.php.net/unsub.php

Re: [PHP-DEV] namespaces and alpha3

[Tony Bibbs]

I'm against ditching it.  This on-again-off-again affair with namespaces really 
should be put to bed as I believe many in the community are really looking 
forward to them.  If it is taken out of 5.3 this same line of logic will be 
used on all subsequent versions.  I don't question it is a hard decision to 
make but waiting doesn't make it easier.

Now that said, I'd be all for holding off if consensus is more time = better 
ideas but from my lurking on the subject it seems this horse has been 
beatingbadly.

--Tony



- Original Message 
From: Geoffrey Sneddon <[EMAIL PROTECTED]>
To: Lukas Kahwe Smith <[EMAIL PROTECTED]>
Cc: PHP Development 
Sent: Friday, October 10, 2008 11:56:11 AM
Subject: Re: [PHP-DEV] namespaces and alpha3


On 10 Oct 2008, at 06:03, Lukas Kahwe Smith wrote:

> 1) rip them out

I'm +1 on this. We simply don't have consensus, and I don't see anyway  
we can have consensus by the time 5.3 has to be frozen. Once  
namespaces are in, we're gonna have to stick with whatever we choose,  
unless we totally break BC.


--
Geoffrey Sneddon



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

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