Re: [PHP-DEV] curl bugfix

[Phil Oleson]

Sure.. even made one for 4.3.1
http://nixil.net/curl.patches.tar.gz

Phil.

Jani Taskinen wrote:


   Can you put that patch somewhere where it can be downloaded?
   (the bug system mangles it..)
   
   --Jani
   

On Wed, 19 Feb 2003, Phil Oleson wrote:

 

Just posted a fix to a crash causing bug in the curl extension.
It's applicable to all revs of php. though I only provided a patch
to HEAD err 5.0 though it should be a quick cut & paste for 4.3.1+

http://bugs.php.net/bug.php?id=22312

Phil.



   



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

[PHP-DEV] curl bugfix

[Phil Oleson]

Just posted a fix to a crash causing bug in the curl extension.
It's applicable to all revs of php. though I only provided a patch
to HEAD err 5.0 though it should be a quick cut & paste for 4.3.1+

http://bugs.php.net/bug.php?id=22312

Phil.


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

[PHP-DEV] RC4 and PHP_AUTH_USER

[Phil Driscoll]

Andrei said he wants to roll RC4 today. Can someone take a look at
http://bugs.php.net/bug.php?id=20441
which is marked as critical for 4.3.0.

Thanks
-- 
Phil Driscoll

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

[PHP-DEV] Re: [PHP-QA] PHP_AUTH_USER

[Phil Driscoll]

On Wednesday 18 December 2002 11:46 pm, Edin Kadribasic wrote:
> I had discussed the issue with Rasmus and Jani some time ago and the
> concensus reached was only to disable PHP_AUTH_USER when safe mode is
> active. Nobody got around to do anything about it though. Is this still an
> acceptable solution?
That would satisfy my customer and anyone else in the same situation, but 
would not satisfy the person who posted the bug in the first place, who I 
suspect would like finer grained control than that, hence my suggestion of 
yet another (sorry!) php.ini option.

Cheers
-- 
Phil Driscoll

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

Re: [PHP-DEV] call_stack

[Phil Dier]

On Wed, 27 Nov 2002 15:41:25 +0100 (CET)
Derick Rethans <[EMAIL PROTECTED]> wrote:

> On Wed, 27 Nov 2002, Miham KEREKES wrote:
> 
> > Hi!
> > 
> > I'm new to this list, I want to know if there is any function which
> > could return the actual call stack, or is it planned to be added?
> > It could be very useful (for example in my case, now :-).
> 
> debug_backtrace() will be available in PHP 4.3.0 and higher.
> 
> Derick
> 

I thought debug_backtrace() was a ze2 thing.  Does that mean 4.3 is going to
use ze2?

Phil Dier

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

[PHP-DEV] Alignment Bug in 'struct sockaddr_storage'

[Phil Oleson]

Hi All,

I've put this in the Bug db as Bug #19508 but I thought faster reaction would
happen if I sent this, as it's in main and not in an extension.

I ran into a alignment problem on my solaris 6 build of php.  This problem was
showing up when it was built with 'Sun Workshop Pro 4' & 'Forte 6', but not gcc.
(I've seen gcc be overly gracious with word alignment before) I pulled out dbx
and tracked down the problem.

I'll cut this short.. Solaris 6 doesnt have it's own copy of sockaddr_storage,
and php's copy is broken. I've put my patches in the notes in the above bug.
Yell if someone wants an email attached version instead.

Phil.


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

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.2.3RC2

[Phil Driscoll]

On Monday 02 September 2002 9:10 pm, [EMAIL PROTECTED] wrote:
> done 2 :)
The page still hasn't updated itself from CVS - is something somewhere not 
running?
-- 
Phil Driscoll

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

Re: [PHP-DEV] Re: [PHP-QA] 4.2.3RC2

[Phil Driscoll]

On Monday 02 September 2002 9:06 pm, [EMAIL PROTECTED] wrote:
> On Mon, 2 Sep 2002, Phil Driscoll wrote:
> > Can someone add RC2 to the buildtest-submit page.
Thanks Derick - any chance of adding bison version 1.33 as well :)


-- 
Phil Driscoll

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

[PHP-DEV] Re: [PHP-QA] 4.2.3RC2

[Phil Driscoll]

Can someone add RC2 to the buildtest-submit page.

Ta

-- 
Phil Driscoll

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

[PHP-DEV] Re: [PHP-QA] PHP 4.2.3 RC1 rolled

[Phil Driscoll]

On Saturday 24 August 2002 9:31 am, [EMAIL PROTECTED] wrote:
> Done. please let me know if something is missing.

We don't seem to be getting the results submitted to 
http://qa.php.net/buildtest-submit.php
posted to the QA list, as we usually do.

Cheers
-- 
Phil Driscoll

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

[PHP-DEV] usort() implementation in 4.1+

[Phil Dier]

I'm sure this has been discussed on here already, but I just discovered the usort() 
behaviour that was 
introduced in php 4.1.0 relating to "equal" values.  Consider this scenario:
id = $id;
$this->time = $time;
}
function do_sort($a,$b)
{
if($a->time == $b->time) return 0;
return ($a->time > $b->time) ? 1 : -1;
}
}
$a3 = new data_object(3, 400);
$a2 = new data_object(2, 400);
$a1 = new data_object(1, 400);
$o_array[0] = &$a1;
$o_array[1] = &$a2;
$o_array[2] = &$a3;
echo ""; 
print_r($o_array);  // the array is in the right order here...
echo "";
usort($o_array, array("data_object","do_sort"));
echo "";
print_r($o_array);  // here it's apparently in the order it is stored in memory...
echo "";
?>

There's obviously a couple workarounds in this simple case, but adding more member 
vars and defining 
objects in different places complicates things.  This behaviour is a bug IMO.  And yes 
I saw the note in 
the manual, but i still think this is counter-intuitive and has the chance to break 
people's code (it broke 
mine).

Phil Dier   <[EMAIL PROTECTED]>
gett communications  <http://www.gettcomm.com>
gett labs, inc.  <http://www.gettlabs.com>


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

[PHP-DEV] __CLASS__ and debug_backtrace()

[Phil Dier]

While experimenting with php-4.3.0 alpha, i discovered this.  Both __CLASS__ and 
debug_backtrace() 
give the wrong class name in the below program and they do so whether the method is 
called statically 
or on an instance.  Is this a bug or the desired behavour?  If the latter, wouldn't it 
be more useful if it 
gave the child class name?
print_something();

?>

Phil Dier   <[EMAIL PROTECTED]>
gett communications  <http://www.gettcomm.com>
gett labs, inc.  <http://www.gettlabs.com>


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

Re: [PHP-DEV] PHP's vision

[Phil Driscoll]

On Monday 03 June 2002 3:35 pm, brad lafountain wrote:

> Now good OO design is the
> best way to get good code re-use out of your time developing.

In your opinion! In my opinion the best way is to think hard and design your 
stuff well. For this I don't need my language fattening up and slowing down 
with OO clutter thank you very much :)

Cheers
-- 
Phil Driscoll

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

[PHP-DEV] Re: [PHP-QA] PHP Test results

[Phil Driscoll]

On Monday 25 March 2002 8:45 pm, [EMAIL PROTECTED] wrote:
> Hello Ian,
>
> I encountered the same thing here very weird (from PHPMyAdmin):
>
> Error
>
> MySQL said:
>
> Host 'localhost.localdomain' is not allowed to connect to this MySQL
> server

Just letting you know that I'm running phpMyAdmin 2.1.0, MySQL 3.23.38 and 
php-4.2.0rc1 on my SuSE 7.3 box here and don't have these problems.

Cheers
-- 
Phil Driscoll

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

[PHP-DEV] Bug #15293 Updated: Incorrect brackets in strlen crashes server

[phil . whittaker]

ID: 15293
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Reproducible crash
Operating System: Linux 2.2.14-5.0 (RedHat 6.2)
PHP Version: 4.0.6
New Comment:

'./configure' '--with-oracle=/u01/app/oracle/product/8.1.6'
'--with-oci8=/u01/app/oracle/product/8.1.6'
'--with-apache=/usr/local/apache_1.3.20' '--enable-sigchild' 

Unfortunately, the server is a live and very active server and I can
not get approval to change to config to add --enable-debug.

Sorry.

Quite interestingly the server runs with 10 httpd processes however
when the script is executed this dramatically increases to approx 70
processes then gradually dies back to 31 processes before hanging. The
time scale for the whole call to hang is round one minute.


Previous Comments:


[2002-01-30 14:52:58] [EMAIL PROTECTED]

Can you provide a backtrace (see
http://bugs.php.net/bugs-generating-backtrace.php) and your
configure-line?



[2002-01-30 03:41:25] [EMAIL PROTECTED]

Using an apache linux box if the brackets are in the wrong place, (see
below) the box spawns hundreds of processes eventually crashing the
server.

(strlen($local[1] < "3"))
[INCORRECT BRACKETS]

Rather than:

(strlen($local[1]) < "3")
[CORRECT BRACKETS]

[Basic php install with sigchild enabled and Oracle support]





Edit this bug report at http://bugs.php.net/?id=15293&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #15293 Updated: Incorrect brackets in strlen crashes server

[phil . whittaker]

ID: 15293
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: Linux 2.2.14-5.0 (RedHat 6.2)
Old PHP Version: 4.0.5
PHP Version: 4.0.6


Edit this bug report at http://bugs.php.net/?id=15293&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #15293: Incorrect brackets in strlen crashes server

[phil . whittaker]

From: [EMAIL PROTECTED]
Operating system: Linux 2.2.14-5.0 (RedHat 6.2)
PHP version:  4.0.5
PHP Bug Type: Reproducible crash
Bug description:  Incorrect brackets in strlen crashes server

Using an apache linux box if the brackets are in the wrong place, (see
below) the box spawns hundreds of processes eventually crashing the
server.

(strlen($local[1] < "3"))
[INCORRECT BRACKETS]

Rather than:

(strlen($local[1]) < "3")
[CORRECT BRACKETS]

[Basic php install with sigchild enabled and Oracle support]
-- 
Edit bug report at: http://bugs.php.net/?id=15293&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #15281: OleMainThreadWndName: php.exe application error

[phil . noon]

From: [EMAIL PROTECTED]
Operating system: Windows NT4 SP6
PHP version:  4.1.1
PHP Bug Type: ODBC related
Bug description:  OleMainThreadWndName: php.exe application error

I am running PHP 4.1.1 as a CGI with Apache 1.3.20. I have an Oracle
database, version 8.1.7, running on the same machine. I am trying to read
the database using ODBC.

I am using the MS ODBC driver for Oracle 2.573.6019.00. I get the same
result using an Oracle ODBC driver.

I get the following error:

"OleMainThreadWndName: php.exe application error"
"The instruction at 0x77f6cc80 referenced memory at 0x0031. The memory
could not be read."

I can connect successfully to the database with no errors using OCI.

 Script --
 
Untitled Document 
 
 
 
Dname 
 

$fname"); 

odbc_close($connectionstring); 

?> 
 
 
 
 End Script --
-- 
Edit bug report at: http://bugs.php.net/?id=15281&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14868: incorrect configuration for --with-java

[phil]

From: [EMAIL PROTECTED]
Operating system: solaris
PHP version:  4.1.0
PHP Bug Type: *Configuration Issues
Bug description:  incorrect configuration for --with-java

There are MULTIPLE problems with what should be a simple
option for configure:

 --with-java=/usr/java1.1

Problem #1: improper detection of javac and jar in PATH.
 I had JAVA_JAR set to "no jar in /usr/bin ."
 Please check to see that there is an actual executable!
Similar problem with javac. 
  ext/java/Makefile hardcodes 'javac', instead of having
  a variable $(JAVAC) set in config_vars.mk, and having
  an executable check done for the var.
[adding /usr/java1.1/bin to my PATH solves both problems]

Additional problem: 
JAVA_INCLUDE =  -I/usr/java1.1/include

is not adequate. It must be

JAVA_INCLUDE = -I/usr/java1.1/include/solaris \   -I/usr/java1.1/include

because jni_md.h is in the solaris subdir.


Once I hand-edited the above valies in config_vars.mk,
the java extention compile successfully with solaris 8.

-- 
Edit bug report at: http://bugs.php.net/?id=14868&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension

[Phil Driscoll]

On Thursday 03 January 2002 11:08 pm, Zak Greant wrote:
> > > Why?
> >
> > Because not everyone wants to use *(#$&ing objects in a simple script!
>
>   No one will be forced to use the wrapper! :)

Whilst this is true, and I know that you are thoughtful and conciencious 
enough to make sure that any new stuff available via OO would also be 
available via a procedural interface, I fear that this might be the start of 
a trend which would spoil PHP.

If you are a web applications developer, there are plenty of mainstream 
options if you like OO. There are fewer if you prefer procedural code, and 
PHP is certainly the natural home for those of us in the latter camp. The 
further PHP moves into the OO camp, the less appealing it becomes for the 
procedural people. Once we have an OO interface to such a mainstream 
extension as mysql (probably *the* most important php extension?), it sends 
an important message to users and developers alike. Then, a couple of years 
down the line, PHP is just another OO toy for those who don't like to be in 
control of their own switch statements :)

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension

[Phil Driscoll]

On Thursday 03 January 2002 2:18 pm, Markus Fischer wrote:
> On Thu, Jan 03, 2002 at 02:06:23PM +0000, Phil Driscoll wrote :
> > Sounds good to me except for the OO wrappers.
> >
> > Do we already have OO wrappers to anything else not in user land? - if so
> > then I'm probably too late to make the point, but to me such a thing
> > feels 'all wrong' and 'not php'. I'm particularly concerned that we don't
> > create functionality which is only accessible by OO means.
>
> Why?

Because I suspect there are plenty of users who either don't know, dislike, 
or actively hate OO programming. PHP started as a procedural language and 
currently has OO as a 'bolt on' (I know this will change with ZE2), but it 
'feels' mainly procedural.

I know that if when I first discovered PHP, if there had been important 
things it wouldn't let me do without resorting to OO then I would have just 
continued using C or moved on down the line to find something else.

I can't believe I'm the only user in that category. The dev list, of course, 
will have a disproportionate number of recent(ish) CS graduates who've been 
through the OO indoctrination classes, so the heated OO discussions here and 
on the ZE2 list may not impact anywhere near as much as you might think on 
the average PHP user.

Cheers

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension

[Phil Driscoll]

Sounds good to me except for the OO wrappers.

Do we already have OO wrappers to anything else not in user land? - if so 
then I'm probably too late to make the point, but to me such a thing feels 
'all wrong' and 'not php'. I'm particularly concerned that we don't create 
functionality which is only accessible by OO means.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposed patch for /php4/win32/install.txt

[Phil Driscoll]

On Friday 28 December 2001 2:03 am, James Cox wrote:
> Since the url specified for browscap.ini is dead, and i can't find a cached
> version, i am proposing a patch to remove the link (And assoc. text) from
> the page.
>

To the best of my knowledge, install.txt is now built by a script which 
generates it from the installation page in the manual. I've CC'd this to the 
doc list where, I'm sure, someone will correct me if I'm wrong. If I'm 
correct, you need to patch the manual page.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: phpweb / downloads.php

[Phil Driscoll]

On Wednesday 12 December 2001 7:23 pm, Gabor Hojtsy wrote:
> > +  
> package"); ?> - 12 >
>
> > +   > installer");
>
> ?> - 12
>
> Are there any plans to make the windows binary file names
> standard... So eg. php-4.1.0-installer.exe sor something alike.
>
> It would be really nice :)

Sorry - my fault - they used to be ok, but it looks like I messed up at some 
point and then continued with the messed up style.

I'll get it right next time :)
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] 4.1.0RC5

[Phil Driscoll]

Built and tested on SuSE 7.2

./configure --with-apxs=/usr/local/httpd/bin/apxs 
--with-mysql=/usr/local/mysql --with-gmp=/usr/local/lib/gmp.

Works great with all my code, Phorum, PHPMyAdmin.
File uploads still work.

make test fails as below:
 [1mRunning tests in /home/phil/php-4.1.0RC5//ext/standard/tests/math [m
=
 [1mVarious pow() tests (pow.phpt)   ... 
failed [m

 [1mRunning tests in /home/phil/php-4.1.0RC5//pear/DB/tests [m
===
 [1mDB_Error/DB_Warning test (db_error.phpt) ... 
failed [m
 [1mDB configurable error handler test (db_error2.phpt)  ... 
failed [m
 [1mDB::factory test (db_factory.phpt)   ... 
failed [m
 [1mDB::isManip test (db_ismanip.phpt)   ... 
failed [m
 [1mDB::parseDSN test (db_parsedsn.phpt) ... 
failed [m


 [1mRunning tests in /home/phil/php-4.1.0RC5//pear/XML/tests [m

 [1mXML Parser: parse simple string (001.phpt)   ... 
failed [m
 [1mXML Parser: parse from file (002.phpt)   ... 
failed [m
 [1mXML Parser: parse from file resource (003.phpt)  ... 
failed [m
 [1mXML Parser: error class (004.phpt)   ... 
failed [m
 [1mXML Parser: mixing character encodings (005.phpt)... 
failed [m

 [1mRunning tests in /home/phil/php-4.1.0RC5//pear/tests [m

 [1mPEAR constructor/destructor test (pear1.phpt)... 
failed [m
 [1mPEAR_Config (pear_config.phpt)   ... 
failed [m
 [1mPEAR_Registry (pear_registry.phpt)   ... 
failed [m

 [1mRunning tests in /home/phil/php-4.1.0RC5//tests/lang [m

 [1mOO Bug Test (Bug #7515) (029.phpt)   ... 
failed [m

TEST RESULT SUMMARY
=
Number of tests:   206
Tests skipped:  92 ( 45%)
Tests failed:   15 ( 13%)
Tests passed:   99 ( 87%)
=
Skipped 0 extensions.
PHP Version: 4.1.0RC5

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] 4.1.0RC5

[Phil Driscoll]

On Monday 03 December 2001 1:53 pm, Zeev Suraski wrote:
> You know the drill, 
...but not the URL - though we could guess :)

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] 4.1.0RC4

[Phil Driscoll]

Built fine on SuSE 7.2.
./configure --with-apxs=/usr/local/httpd/bin/apxs 
--with-mysql=/usr/local/mysql --with-gmp=/usr/local/lib/gmp.

Works great with all my code, Phorum, PHPMyAdmin.

make test fails as below:

 [1mRunning tests in /home/phil/php-4.1.0RC4//pear/DB/tests [m
===
 [1mDB_Error/DB_Warning test (db_error.phpt) ... 
failed [m
 [1mDB configurable error handler test (db_error2.phpt)  ... 
failed [m
 [1mDB::factory test (db_factory.phpt)   ... 
failed [m
 [1mDB::isManip test (db_ismanip.phpt)   ... 
failed [m
 [1mDB::parseDSN test (db_parsedsn.phpt) ... 
failed [m


 [1mRunning tests in /home/phil/php-4.1.0RC4//pear/XML/tests [m

 [1mXML Parser: parse simple string (001.phpt)   ... 
failed [m
 [1mXML Parser: parse from file (002.phpt)   ... 
failed [m
 [1mXML Parser: parse from file resource (003.phpt)  ... 
failed [m
 [1mXML Parser: error class (004.phpt)   ... 
failed [m
 [1mXML Parser: mixing character encodings (005.phpt)... 
failed [m

 [1mRunning tests in /home/phil/php-4.1.0RC4//pear/tests [m

 [1mPEAR constructor/destructor test (pear1.phpt)... 
failed [m
 [1mPEAR_Config (pear_config.phpt)   ... 
failed [m
 [1mPEAR_Registry (pear_registry.phpt)   ... 
failed [m


 [1mRunning tests in /home/phil/php-4.1.0RC4//tests/lang [m

 [1mOO Bug Test (Bug #7515) (029.phpt)   ... 
failed [m

TEST RESULT SUMMARY
=
Number of tests:   206
Tests skipped:  92 ( 45%)
Tests failed:   15 ( 13%)
Tests passed:   99 ( 87%)
=
Skipped 0 extensions.
PHP Version: 4.1.0RC4

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Win32 Build for 4.1.0

[Phil Driscoll]

I've posted a windows installer version of 4.1.0 at
http://www.dialsolutions.com/phil/php/php410-installer.exe

The php.ini it installs is based on the php.ini-recommended since AFAIR the 
4.1.0 release was intended to jolt people into using register_globals=off etc.
If it should be based on ini-dist, shout and I'll brew up another in the 
morning.

I've tested that it installs (and - new for this version - uninstalls) ok, 
but I don't have a windows box with a working web server on it so I'd be 
grateful if someone could put it through its paces before it goes out the 
door.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Win32 Build for 4.1.0

[Phil Driscoll]

For the installer, should I install a php.ini based on php.ini-dist or 
php.ini-recommended?

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Win32 Build for 4.1.0

[Phil Driscoll]

On Monday 26 November 2001 11:52 pm, Phil Driscoll wrote:

> There's no msvcrt.dll in the zip - I guess this will be some users who
> don't already have it.

I guess *there* will be some users...

Not enough sleep - sorry :)
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Win32 Build for 4.1.0

[Phil Driscoll]

On Monday 26 November 2001 10:27 pm, Daniel Beulshausen wrote:
> At 18:40 26.11.2001 +, James Moore wrote:
> >You happy to build this for the release? I would but Ive got library
> >problems here :)
>
> please take a look at http://www.php4win.com/~daniel/php-4.1.0-Win32.zip
> be warned however, that i nuked some old dll's and am not 100% sure wether
> there's an unfulfilled dependency now.
> i didn't discovered anything suspicious, but who knows...

There's no msvcrt.dll in the zip - I guess this will be some users who don't 
already have it.

The installer expects to install one so I'll use the one we shipped with 
4.0.6 unless someone shouts.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status

[Phil Driscoll]

On Wednesday 21 November 2001 6:14 pm, Brian Moon wrote:
> You might have thought it was junk, but did you look at the one from the
> Nullsoft guys?
>
> http://www.nullsoft.com/free/nsis/
>
I didn't find it when I lookd - however, it looks like it's not junk :)
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status

[Phil Driscoll]

On Wednesday 21 November 2001 4:50 pm, James Moore wrote:

> Well if your happy doing the installer for now thats fine
I'm happy doing it, but sad that I never seem to find time to make it any 
better :) It's main drawback at the moment is that it relies on an OCX 
control which is not present on a small proportion of machines, and that it 
doesn't attempt to edit httpd.conf for an Apache installation. If we wanted 
to extend the functionality to include PEAR then unless it is a simple matter 
of copying the pear stuff to a particular location, I'm not familiar enough 
with PEAR to do a decent job. I would be happy to hand over the reigns though 
:)

> I was just
> looking at installshield for a PEAR install system due to the fact it
> installshield developer 7 looked more extensable to me :)

Maybe it is now - at the point in time I did the research (maybe 18 months 
ago) Wise seemed to be ahead of the game. What would be really great would be 
a free Windows installer, but sadly everything I found in that regard was 
junk.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status

[Phil Driscoll]

On Wednesday 21 November 2001 4:14 pm, James Moore wrote:

> As I posted when RC3 came out:
> http://www.phpuk.org/~james/php-4.1.0RC3-win32.zip I also have a nice
> installshield script that creates a distributable msi installer but its not
> quite finished yet (havnt done sapi installation or php.ini altering but I
> will sort that probably not for 4.1.0 but defintatly for 4.2.0, would
> anyone have a problem if I approached installshield software to get us a
> license for their developer version. I was looking at it for possible
> integration with the PEAR installer which Stig is working on I belive)..
> Ill build a few more extensions tonight and add them to the zip already
> available I just need to sort out hyperwave, domxml, xslt and a few of the
> more obsecure extensions then I should be able to build them all.

If it's any use to you, I bought a licence for Wise Install Builder solely 
for the purpose of building the PHP windows installation stuff. I chose the 
Wise software because it seemed significantly more capable than the 
InstallShield stuff. Anyway, since it was bought for the job, I'd be more 
than happy to transfer the licence to you. Needless to say, your existing 
installshield script won't work, but you could have the Wise script I built.

I avoided the MSI stuff when I started the installer because for most users 
it meant a significant extra download from microsoft before they could use 
it, but maybe the world has changed since then and more users have the 
microsoft installation stuff already on their machines.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.1.0 Final RC

[Phil Driscoll]

Built without problems on SuSE 7.2
./configure --with-apxs=/usr/local/httpd/bin/apxs 
--with-mysql=/usr/local/mysql --with-gmp=/usr/local/lib/gmp

Tested with all my code (including file uploads which worked perfectly) along 
with phpmyadmin and phorum - no problems found.

Make test failed as follows:

 [1mRunning tests in /home/phil/php-4.1.0RC3//ext/standard/tests/math [m
=
 [1mVarious pow() tests (pow.phpt)   ... 
failed [m
 [1mRunning tests in /home/phil/php-4.1.0RC3//pear/DB/tests [m
===
 [1mDB_Error/DB_Warning test (db_error.phpt) ... 
failed [m
 [1mDB configurable error handler test (db_error2.phpt)  ... 
failed [m
 [1mDB::factory test (db_factory.phpt)   ... 
failed [m
 [1mDB::isManip test (db_ismanip.phpt)   ... 
failed [m
 [1mDB::parseDSN test (db_parsedsn.phpt) ... 
failed [m

 [1mRunning tests in /home/phil/php-4.1.0RC3//pear/XML/tests [m

 [1mXML Parser: parse simple string (001.phpt)   ... 
failed [m
 [1mXML Parser: parse from file (002.phpt)   ... 
failed [m
 [1mXML Parser: parse from file resource (003.phpt)  ... 
failed [m
 [1mXML Parser: error class (004.phpt)   ... 
failed [m
 [1mXML Parser: mixing character encodings (005.phpt)... 
failed [m

 [1mRunning tests in /home/phil/php-4.1.0RC3//pear/tests [m

 [1mPEAR constructor/destructor test (pear1.phpt)... 
failed [m
 [1mPEAR_Config (pear_config.phpt)   ... 
failed [m
 [1mPEAR_Registry (pear_registry.phpt)   ... 
failed [m

 [1mRunning tests in /home/phil/php-4.1.0RC3//ext/standard/tests/math [m
=
 [1mVarious pow() tests (pow.phpt)   ... 
failed [m
 [1mRunning tests in /home/phil/php-4.1.0RC3//pear/DB/tests [m
===
 [1mDB_Error/DB_Warning test (db_error.phpt) ... 
failed [m
 [1mDB configurable error handler test (db_error2.phpt)  ... 
failed [m
 [1mDB::factory test (db_factory.phpt)   ... 
failed [m
 [1mDB::isManip test (db_ismanip.phpt)   ... 
failed [m
 [1mDB::parseDSN test (db_parsedsn.phpt) ... 
failed [m

 [1mRunning tests in /home/phil/php-4.1.0RC3//pear/XML/tests [m

 [1mXML Parser: parse simple string (001.phpt)   ... 
failed [m
 [1mXML Parser: parse from file (002.phpt)   ... 
failed [m
 [1mXML Parser: parse from file resource (003.phpt)  ... 
failed [m
 [1mXML Parser: error class (004.phpt)   ... 
failed [m
 [1mXML Parser: mixing character encodings (005.phpt)... 
failed [m

 [1mRunning tests in /home/phil/php-4.1.0RC3//pear/tests [m

 [1mPEAR constructor/destructor test (pear1.phpt)... 
failed [m
 [1mPEAR_Config (pear_config.phpt)   ... 
failed [m
 [1mPEAR_Registry (pear_registry.phpt)   ... 
failed [m


 [1mRunning tests in /home/phil/php-4.1.0RC3//tests/lang [m

 [1mOO Bug Test (Bug #7515) (029.phpt)   ... 
failed [m

TEST RESULT SUMMARY
=
Number of tests:   206
Tests skipped:  92 ( 45%)
Tests failed:   15 ( 13%)
Tests passed:   99 ( 87%)
=
Skipped 0 extensions.
PHP Version: 4.1.0RC3


-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] 4.1.0RC2

[Phil Driscoll]

Built and tested on SuSE 7.2. Configure line:
--with-apxs=/usr/local/httpd/bin/apxs
--with-mysql=/usr/local/mysql
--with-gmp=/usr/local/lib/gmp

No build problems.
Works without problems with all my code, phpmyadmin and phorum.
Make test produces the following fails:

Running tests in /home/phil/php-4.1.0RC2//ext/standard/tests/file
=
File type functions (001.phpt)  ... failed 

Running tests in /home/phil/php-4.1.0RC2//ext/standard/tests/math
=
Various pow() tests (pow.phpt)  ... failed 
Simple math tests (round.phpt)  ... failed 
Running tests in /home/phil/php-4.1.0RC2//pear/DB/tests
===
DB_Error/DB_Warning test (db_error.phpt)  ... failed 
DB configurable error handler test (db_error2.phpt)   ... failed 
DB::factory test (db_factory.phpt)... failed 
DB::isManip test (db_ismanip.phpt)... failed 
DB::parseDSN test (db_parsedsn.phpt)  ... failed 

Running tests in /home/phil/php-4.1.0RC2//pear/XML/tests

XML Parser: parse simple string (001.phpt)... failed 
XML Parser: parse from file (002.phpt)... failed 
XML Parser: parse from file resource (003.phpt)   ... failed 
XML Parser: error class (004.phpt)... failed 
XML Parser: mixing character encodings (005.phpt) ... failed 

Running tests in /home/phil/php-4.1.0RC2//pear/tests

PEAR constructor/destructor test (pear1.phpt) ... failed 
PEAR_Config (pear_config.phpt)... failed 
PEAR_Registry (pear_registry.phpt)... failed 

 
TEST RESULT SUMMARY
=
Number of tests:   206
Tests skipped:  92 ( 45%)
Tests failed:   17 ( 15%)
Tests passed:   97 ( 85%)
=
Skipped 0 extensions.

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: RC3

[Phil Driscoll]

On Friday 05 October 2001 9:02 am, Hellekin O. Wolf wrote:
> At 16:31 05/10/2001 +0900, Yasuo Ohgaki wrote:
> >Yasuo Ohgaki wrote:
> >>Yasuo Ohgaki wrote:
> >>>Zeev Suraski wrote:
> >>>>Finally, it's out.
> >>>>www.php.net/~zeev/php-4.0.7RC3.tar.gz
> >>
> >>In addition to previous problem, CGI build seems to print following line
> >>again..
> >
> >Minor problems with phpinfo() while running PHP as Apache module.
> >
> >Logo images(PHP/Zend) are not displayed.
>
> *** I don't have those problems. Can you reproduce ?
Likewise - all logos are there for me while running PHP as Apache module.

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RC3

[Phil Driscoll]

On Thursday 04 October 2001 11:29 am, Phil Driscoll wrote:
> All my stuff, Phorum and phpMyAdmin seems to work fine.
This shoulc have read
 All my stuff, plus Phorum and phpMyAdmin seem to work fine.
I wasn't trying to claim credit for Phorum and phpMyAdmin :)

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RC3

[Phil Driscoll]

On Thursday 04 October 2001 1:04 am, Zeev Suraski wrote:
> Finally, it's out.
> www.php.net/~zeev/php-4.0.7RC3.tar.gz
Built and tested on SuSE 7.2 as apache module with Apache 1.3.20
--with-apxs=/usr/local/httpd/bin/apxs
--with-mysql=/usr/local/mysql
--with-gmp=/usr/local/lib/gmp

All my stuff, Phorum and phpMyAdmin seems to work fine.

here's the output of the fails in make test
Running tests in /home/phil/php-4.0.7RC3//ext/standard/tests/file
=
File type functions (001.phpt)   ... 
failed 

Running tests in /home/phil/php-4.0.7RC3//ext/standard/tests/math
=
Simple math tests (001.phpt) ... 
failed Various pow() tests (pow.phpt)   
... failed 
Running tests in /home/phil/php-4.0.7RC3//ext/standard/tests/time
=
microtime() function (001.phpt)  ... 
failed strtotime() function (002.phpt)  
... failed 
Running tests in /home/phil/php-4.0.7RC3//pear/DB/tests
===
DB_Error/DB_Warning test (db_error.phpt) ... 
failed DB configurable error handler test (db_error2.phpt)  
... failed DB::factory test (db_factory.phpt) 
  ... failed DB::isManip test (db_ismanip.phpt)   
... failed DB::parseDSN test (db_parsedsn.phpt)   
  ... failed 
Running tests in /home/phil/php-4.0.7RC3//pear/XML/tests

XML Parser: parse simple string (001.phpt)   ... 
failed XML Parser: parse from file (002.phpt)   
... failed XML Parser: parse from file resource (003.phpt)
  ... failed XML Parser: error class (004.phpt)   
... failed XML Parser: mixing character encodings (005.phpt)  
  ... failed 
Running tests in /home/phil/php-4.0.7RC3//pear/tests

PEAR constructor/destructor test (pear1.phpt)... 
failed PEAR_Error test (pear_error.phpt)
... failed PEAR_Error in die mode (pear_error2.phpt)  
  ... failed PEAR default error handling (pear_error3.phpt)   
... failed 
Running tests in /home/phil/php-4.0.7RC3//tests/lang

OO Bug Test (Bug #7515) (029.phpt)   ... 
failed
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RC3

[Phil Driscoll]

On Thursday 04 October 2001 1:04 am, Zeev Suraski wrote:
> Finally, it's out.
> www.php.net/~zeev/php-4.0.7RC3.tar.gz
Builds fine on NT4 as cgi (Release_TS_Inline) and phpinfo works ok under IIS.

When I try to build the test suite I get the following output - I don't know 
if this means that things went ok or not!

Configuration: testsuite - Win32 
Release_TS
Build : warning : failed to (or don't know how to) build 
'E:\F\php\php-4.0.7RC3\results.txt'
Running Testsuite, please wait...

testsuite - 0 error(s), 40 warning(s)

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [Zend Engine 2] Right/Left Shift Zero Fill operator

[Phil Driscoll]

+1 for >>>

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] IIS/PWS Config done by PHP

[Phil Driscoll]

On Friday 07 September 2001 10:03 pm, [EMAIL PROTECTED] wrote:
> Hi,
>
> I'm curious to know how PHP configures IIS/PWS to let itself handle all
> requests for files ending in .php, etc. How is it done?
>
> Is it the same for IIS and PWS?

IIS 3 and below is effectively the same as PWS on win 9x platforms and uses 
the registry for configuration. IIS4 and above uses a thing called the IIS 
metabase for configuration, and is effectively the same as PWS on NTWS and 
above.

> Is the configuration different for using
> PHP as a CGI and as an ISAPI module?
AFAIK, the PHP ISAPI module is not officially supported on IIS3, but on IIS 4 
the configuration differs in that the script mapping points to the 
php4isapi.dll rather than php.exe and also that php4isapi.dll is added to the 
list of ISAPI filters so that it can get its hands on authentication 
information.

>
> PHP puts a string value under the "Script Map" registry key, but adding
> just a new string value for a new file extension doesn't work. So this
> can't be it?

That is what the installer does. It seems to work on the machines I've tested 
it on. If it should do more or something else, let me know so I can update 
the installer.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] RC2

[Phil Driscoll]

I can confirm that RC2 Release_TS_Inline CGI version builds ok on NT4 and 
phpinfo() does its stuff.

I'm not sure what the testsuite project does, but when I build it I get 0 
errors and 0 warnings.

On SuSE 7.2 (2.4 kernel) it builds without problem with the following 
configure line:

./configure --with-apxs=/usr/local/httpd/bin/apxs 
--with-mysql=/usr/local/mysql --with-gmp=/usr/local/lib/gmp

however at the end of make install I get this message which I haven't seen on 
previous builds.

cp: cannot stat `scripts/phptar': No such file or directory

Having said that, it seemed to install ok, and all my code, phorum and 
phpmyadmin work fine.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] 4.0.7RC1 rolled

[Phil Driscoll]

On Thursday 16 August 2001 6:35 pm, Phil Driscoll wrote:
> On Thursday 16 August 2001 4:56 pm, Harald Radi wrote:
> > could you or someone else provide a windows binary of RC1.
> >
> > regards
>
> It will be at
> http://www.dialsolutions.com/phil/php/php-4.0.7RC1win32.zip
> in a few minutes when I've brewed up a version which includes crypt.
In the light of Zeev's binary, I withdraw the above :)

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] 4.0.7RC1 rolled

[Phil Driscoll]

On Thursday 16 August 2001 4:56 pm, Harald Radi wrote:
> could you or someone else provide a windows binary of RC1.
>
> regards
It will be at
http://www.dialsolutions.com/phil/php/php-4.0.7RC1win32.zip
in a few minutes when I've brewed up a version which includes crypt.

Cheers

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.7RC1 rolled

[Phil Driscoll]

On Thursday 16 August 2001 11:25 am, Zeev Suraski wrote:
> You're building Release_TSDbg, right?
Good call. Release_TS builds fine.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] 4.0.7RC1 rolled

[Phil Driscoll]

On Thursday 16 August 2001 10:32 am, Alexander Wirtz wrote:
> >Just built RC1 on SuSE7.2 with
> >./configure --with-apxs=/usr/local/httpd/bin/apxs
> >--with-mysql=/usr/local/mysql --with-gmp=/usr/local/lib/gmp
> >
> >Built fine, works perfectly on all my code + Phorum +PHPMyAdmin.
>
> Could you please try to build it as cgi? My build failed, as you may see in
> previous mails, but I'd like to see, if there are others with the same
> problem.
>
Done - built with no problems.
Here's the output of make test:

TEST RESULT SUMMARY
=
Number of tests:   197
Tests skipped:  88 ( 45%)
Tests failed:   20 ( 18%)
Tests passed:   89 ( 82%)

and the fails are:

Running tests in /home/phil/php-4.0.7RC1//ext/standard/tests/file
=
File type functions (001.phpt)   ... failed

Running tests in /home/phil/php-4.0.7RC1//ext/standard/tests/math
=
Simple math tests (001.phpt) ... failed 
Various pow() tests (pow.phpt)   ... failed

Running tests in /home/phil/php-4.0.7RC1//ext/standard/tests/time
=
microtime() function (001.phpt)  ... failed 
strtotime() function (002.phpt)  ... failed

Running tests in /home/phil/php-4.0.7RC1//pear/DB/tests
===
DB_Error/DB_Warning test (db_error.phpt) ... failed 
DB configurable error handler test (db_error2.phpt)  ... failed 
DB::factory test (db_factory.phpt)   ... failed 
DB::isManip test (db_ismanip.phpt)   ... failed 
DB::parseDSN test (db_parsedsn.phpt) ... failed

Running tests in /home/phil/php-4.0.7RC1//pear/XML/tests

XML Parser: parse simple string (001.phpt)   ... failed 
XML Parser: parse from file (002.phpt)   ... failed 
XML Parser: parse from file resource (003.phpt)  ... failed 
XML Parser: error class (004.phpt)   ... failed 
XML Parser: mixing character encodings (005.phpt)    ... failed 

Running tests in /home/phil/php-4.0.7RC1//pear/tests

PEAR constructor/destructor test (pear1.phpt)... failed 
PEAR_Error test (pear_error.phpt)... failed 
PEAR_Error in die mode (pear_error2.phpt)... failed 
PEAR default error handling (pear_error3.phpt)   ... failed

Running tests in /home/phil/php-4.0.7RC1//tests/lang

OO Bug Test (Bug #7515) (029.phpt)   ... failed


-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.7RC1 rolled

[Phil Driscoll]

Just tried to build on Windows but got the following warning & error.

E:\F\php\php-4.0.7RC1\php-4.0.7RC1\ext\calendar\jewish.c(270) : warning 
C4005: 'SDN_OFFSET' : macro redefinition
E:\F\php\php-4.0.7RC1\php-4.0.7RC1\ext\calendar\gregor.c(0) : see 
previous definition of 'SDN_OFFSET'

...

   Creating library cyr_convert.lib and object cyr_convert.exp
LINK : fatal error LNK1561: entry point must be defined
Error executing cl.exe.

php.exe - 1 error(s), 36 warning(s)

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] 4.0.7RC1 rolled

[Phil Driscoll]

Just built RC1 on SuSE7.2 with
./configure --with-apxs=/usr/local/httpd/bin/apxs
--with-mysql=/usr/local/mysql --with-gmp=/usr/local/lib/gmp

Built fine, works perfectly on all my code + Phorum +PHPMyAdmin.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Portability concerns

[Phil Driscoll]

On Saturday 04 August 2001 22:06, Stig Sæther Bakken wrote:

> Say PHP had a function to put it in "portable mode" changing the
> behaviour of a few functions.  Then for example PEAR classes would
> have to deal with running both with and without this mode, since the
> user can enable or disable it at will.  So this would in fact add
> complexity to the process of writing portable PHP code.

No this isn't the case. You can drop in and out of this mode in your own 
code, so PEAR classes would switch into it and there would be no problem.

> I think André is right that it's better to educate users (for example
> by telling them to disable magic_quotes :-).

I agree about the education bit as well, but I think it would be good to have 
a mechanism that help to future proof old code for when the rules changed.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Portability concerns

[Phil Driscoll]

On Saturday 04 August 2001 15:03, André Næss wrote:

>
> I don't like the idea of a function like this, I think it's much more
> important to educate people on how they write portable PHP code (to the
> extent possible).

That is my point really - what constitutes 'portable code' has changed quite 
a bit over the time I've been using PHP. I was hoping to provoke
discussion of a mechanism whereby such changes might be made without breaking 
code, or changing the rules as to what constitutes portable code.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Portability concerns

[Phil Driscoll]

On Saturday 04 August 2001 08:49, Stig Sæther Bakken wrote:
> [Phil Driscoll <[EMAIL PROTECTED]>]
>
> With such a php_portability() function, it would be _even_ harder to
> write portable library code (because you need to handle both
> settings).  Two wrongs won't make this one right. :-)
>
Please explain!



-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues (isset stuff)

[Phil Driscoll]

On Monday 30 July 2001 11:52, Phil Driscoll wrote:

> Some people agree with me, others disgree. As long as you have conrol of
> your php.ini file, it isn't a problem :) - although it will (indeed already
> does!) tend to discourage me, and probably others, from releasing any of my
> code for public consumption.

But I should have added that a good implementation of import_globals will 
remove that discouragement!

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues (isset stuff)

[Phil Driscoll]

On Monday 30 July 2001 11:13, [EMAIL PROTECTED] wrote:
> Hi Phil!
> Yes Phil, but does your codes rely on warnings messages alone?
No - my code relies on exceedingly thorough and paranoid validation of input, 
carefully constructed program flow, painstaking testing at all stages and no 
doubt thousands of other things my brain does unconsciously due to over 20 
years of programming experience.

I cannot imagine a single error I would make which register_globals=off would 
cure, that setting error reporting to E_ALL would not highlight during 
testing.

Some people agree with me, others disgree. As long as you have conrol of your 
php.ini file, it isn't a problem :) - although it will (indeed already does!) 
tend to discourage me, and probably others, from releasing any of my code for 
public consumption.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues - a bit of my experience

[Phil Driscoll]

On Sunday 29 July 2001 19:42, Stephen van Egmond wrote:
>will produce warnings if $x is not set.  If you don't want the
>warnings, you have to replace it with:
>
>   if (isset($x) && $x) {
>   }
>
>"if it's set and it's true"...? ugh.
>
> One is then tempted to look for replacement functions in the
> library, and immediately hits upon empty.
>
>   if (!$empty)
>
> But as can be seen from the table at
> http://bang.dhs.org/~svanegmond/logictest.php , empty()
> returns TRUE if you hand it a boolean FALSE! Otherwise, the semantics
> of empty() are a good replacement for the warning-generating cast to
> boolean.

I agree - to my mind empty is broken in this respect and also in the respect 
that it returns true for a string containing '0'. Consequently I (and I 
assume everyone else, unless I'm missing some occasion that this behaviour is 
useful) can never use empty in my code.

Zeev was recently saying that he believed empty() was not as popular as 
isset() - and I suspect this is the reason.

I think that empty() (for scalars) really should behave thus:

function empty($var)
{
 return !(isset($Var) && strcmp($var,''));
}

as this is what needs to be done over and over again to validate form input.
Maybe people really do use empty, so changing the behaviour will break loads 
of code. In which case an extra parameter $Useful, could be set to true to 
give useful behaviour :)

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues (isset stuff)

[Phil Driscoll]

On Sunday 29 July 2001 19:13, [EMAIL PROTECTED] wrote:
...stuff pointing out how you'd get no warning messages when the evil guy 
sets the variables from outside.

You missed my point, which is the good guy would get the warning messages 
when he tested the code himself without sending in the 'bad' variables. 
There's no point showing the warning messages to the bad guy!

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues

[Phil Driscoll]

On Sunday 29 July 2001 17:35, Zeev Suraski wrote:
> *sigh* :)  As I said numerous times, PHP gives you standard clean ways to
> test your variables without generating E_NOTICE's, namely, isset() (very
> popular) and empty() (less popular, but available all the same).  There's a
> good, fairly darned good chance that exploitable code will generate no
> warnings whatsoever, and that code that was written with cleanliness in
> mind will actually be more difficult to debug than sucky
> E_NOTICE-generating code would.

We'll have to agree to differ - Over the last year I must have downloaded 
about 50 PHP scripts from the popular places with a view to using them. ALL 
of them - yes every last one - generated warning messages under E_WARNING. 
People who code sloppily, code sloppily, the warning messages will get out. 
Even people who code well but don't test under E_WARNING will find that 
E_WARNING is their friend. I don't think that the typical uses of isset and 
empty actually serve to hide the warning messages that would appear in 
vulnerable code.

Anyway, I'll shut up now and leave you in peace :)

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposal

[Phil Driscoll]

On Sunday 29 July 2001 07:57, Zeev Suraski wrote:
> I'm against a global function like this, but in favour of the 2nd flavour,
> where you have to explicitly pass a list of variable names to import.  I
> also think that it should only support prefix globbing, other types of
> globbing are prone to errors, and also slow to implement.

There is an issue that import_globals('GPC') is surely a better option - if 
you are of the opinion that this register globals stuff helps :) - than 
setting register_globals=on since it only applies to the one script rather 
than all scripts, and it may be all that is available as a quick fix for some 
of the scripts out there.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues

[Phil Driscoll]

On Saturday 28 July 2001 20:52, Zeev Suraski wrote:

a rebuf to each of my arguments :)

Rather than prolong the agony, my point is that in all the cases where a 
malicious user has the chance to inject a dodgy variable, the code must 
normally have a logic path which allows the code to pass through an undefined 
usage of that variable. In testing the code with E_NOTICE on, a warning 
message will be displayed. The warning message could be beefed up to scare 
the user a bit more, but for me it is this that hits the nail on the head.

I can assure you that the monkeys will screw things up whowever you change 
the code :)

That said, It's easy to live with the proposal, especially with the 
import_globals() functions.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] thread safety

[Phil Driscoll]

Zeev

If the thread safety stuff you've just committed might fiz the ISAPI 
problems, and you want some testing doing, please shout out.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues

[Phil Driscoll]

Apologies in advance to Zeev for arguing on this one, but be assured I firmly 
believe that your solution would be to the detriment of PHP and a better 
solution is possible :)

On Saturday 28 July 2001 12:44, Zeev Suraski wrote:
>
> NO!! :)  Saying people would stop using PHP (or won't get started) because
> of this change is a gross exaggeration.  IMHO, the one and only issue at
> hand here is downwards compatibility, and not usability or ease of use, not
> even a bit.

Sorry Zeev - the answer is YES. I and no doubt thousands of others will turn 
register_globals on because it gives much more readable code, much less 
typing and does not IMHO add one jot to the security of my applications.

> That's not going to find half, or a quarter, or whatever of the problems,
> since PHP has tools to cleanly handle undefined variables - namely isset()
> and empty().  They, or at least isset(), are quite popular.

I always use something like:

if(!isset($Thing) /*and possibly some range checking*/))
 $Thing="sensible default";

In no way is

if(!isset(_GET['Thing']) /*and possibly some range checking*/))
{
 $Thing="sensible default";
}
else
{
 $Thing=(_GET['Thing']);
}

any more secure (nor would it be if I wrote "sensible default" back to _GET.

Anyway, to check my sanity i have reread the security advisory which I first 
read on the day it was published, and I am even more conviced now that 
register globals=off has the tiniest of effects for gpc variables wheras 
E_NOTICE has a massive effect.

Here are the examples from the advisory:

--
 

replace $pass with _GET['pass']  and the code is 
equally insecure. Turn E_NOTICE on and the novice programmer will get a 
warning message for the unset $pass.
--
 \n");
 ?>

replace $filename with _GET['filename'] and this lunatic piece of code 
remains a lunatic piece of code. If $filename is not meant to be coming from 
the outside world then with E_NOTICE on there would be a warning message for 
the unset filename.
--
 
Ok, with register_globals=off then $libdir could not be directly overwritten 
from outside (unless there was some code which made that happen) however 
E_NOTICE would generate a warning for an unset $libdir
--
File upload.
If you don't use the new functions you are potentially stuffed with register 
globals on or off.
As an aside - we could have a php.ini directive which could 'break' code 
which did not use the new functions - if we save an uploaded file with one 
name, but set the $userfile_name to something else, and only rename the 
original to $userfile_name after a call to is_uploaded_file or 
move_uploaded_file.
--
 

This seems to be the same as the fopen($filename... example above.
--
In libdir/loadlanguage.php:
 

include files called out of context. The solution is to configure your web 
server, or put the include files outside the webroot so that they cannot be 
run out of context.

In this example, typically $langdir should have been set inside the 
application or a configuration file, but $userLang will typically have come 
from the user either with this request, or previously and stored in a 
database in the users profile.

So under the register_globals = off scheme, we would often end up with 
something along the lines of:



where $langDir is unset. We can all see how secure that is :)
--
Session files.

I am happy to concede that there should be a php.imi directive which stops 
variables which can more or less be trusted, such as env and session from 
entering the global namespace, so that if you want to read them you have to 
look in the correct place.
--

In conclusion I would urge those who want to set register_globals=off to 
reconsider. A better solution is required. The better solution involves some, 
all, or more of:
E_WARNING
more granularity to the register_globals directive
the file upload changes I mentioned as an aside


Cheers 
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues

[Phil Driscoll]

On Friday 27 July 2001 17:35, Zeev Suraski wrote:

> Have you read the advisory?  That's simply not true.

Yes, and I beleive it is true in most cases.

> There are two main types of security problems related to this:
> (a) Ones that originate in the fact that people don't know they mustn't
> trust any input coming from the user, be it GET, POST or cookies, that
> they're all insecure

So, you admit that register_globals=off for GPC variables gains us nothing, 
but will break shed loads of code?

> (b) Ones that don't, and there are many of them
>
> For those of type (a), register_globals being off or on doesn't change
> much.  For (b), it does, big time.

Then if you don't like my suggestion, how about a half way house - 
register-globals=GPC registers the insecure variables in the global namespace 
since we can't trust them wherever they appear in the namespace, whilst env 
variables and possibly session variables have to be read out of arrays.
I know that this would break none of my scripts, but I can't speak for other 
scripts out there.

I do feel, however, that you are really missing the point on E_NOTICE which 
IMHO has a much greater effect on the security of PHP than accessing GPC 
variables in a different way. I'd personally be even harsher than E_NOTICE is 
- if a production site generates a notice message for an uninitialised 
variable, then that's a fatal error in my book!

Cheers
-- 
Phil Driscoll


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues

[Phil Driscoll]

On Friday 27 July 2001 12:51, Marc Boeren wrote:
> if ($internal_variable == 'whatever') {
> // do something, knowing that a user could never have set this
> }
>
> The second check is where a lot of scripts are exploitable, I think, if
> register_globals=on, because programmers do not expect user-input in this
> variable.

...but will be caught perfectly by E_ALL
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues

[Phil Driscoll]

I must be much more stupid than I give myself credit for.

Changing to register globals=off surely does very little in terms of security 
for the easily fakeable GPC variables. I can see that for environment 
variables the picture is slightly different - you do need to be sure that 
this *really* is an  SSL connection etc.

I propose the following - which will break *NO* scripts.

Examine the environment variable issues such as those which pertain to SSL 
and then, just as recently happened with the file upload vulnerability, 
implement some functions which do 'full strength' checking for the user
e.g. is_secure_connection()

Then to address the uninitialised variables issue, modify the error reporting 
system so that the default setting (E_SECURE) emails warnings and errors to 
the administrator rather than displaying them in the output.

Maybe some other refinement of the technique involving a sensible mixture of 
display_error, error_reporting, and a new email_errors directive might be 
better.

With this solution, we break no scripts and we encourage more secure 
programming.

So now, tear it to pieces :)

Cheers
-- 
Phil Driscoll


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Security Issues

[Phil Driscoll]

On Wednesday 25 July 2001 15:31, Rasmus Lerdorf wrote:

> The change I would rather see in php.ini would be to have the default
> error_level be set to E_ALL because then the above script would generate a
> warning complaining about the fact that $ok was not initialized.  Since
> PHP can determine when variables are not initialized the case for
> turning register_globals off in this example is rather weak.

+1

The security issue is poor coding rather than anything else. Using the 
various VAR arrays largely moves the problem sideways.

I took the liberty on the Windows installer of making the default route 
through the wizard set the error level to E_ALL. I am fed up that almost all 
the freely available PHP scripts out there just won't run at E_ALL because 
they either spew out so many warning messages that you can't see what's going 
on, and in many cases, the warning messages cause crucial headers not to be 
sent. My own rule of thumb is that if a script outputs any warnings during 
normal use, then it just can't be trusted to be secure.

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #11997: PHP Won't work on XP 2

[Phil Driscoll]

On Tuesday 10 July 2001 04:24, Joey Smith wrote:
> Geez...is this not in the FAQ? It really should be...
> Perhaps, for the next installer, this msg could be modified to:
>
> "Unable to configure webserver, due to a missing OCX control on your
> system, the install Wizard is unable to configure your web
> server. However, PHP has been sucessfully installed. For more
> information, please see . PLEASE DO NOT POST THIS TO THE
> BUG DATABASE!"

Well - as it happens, the error message in full actually reads

"Due to a missing OCX control on your system, the installation Wizard is 
unable to configure your web server.  However, PHP has been successfully 
installed, and all you need to do now is manually configure the web server as 
described in the install.txt file which can be found in your php installation 
directory."

Which, surprisingly, is exactly what the user needs to do!


-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] php 4.1 or php 5.0

[Phil Driscoll]

On Wednesday 04 July 2001 17:12, Brian Moon wrote:
> FWIW, I am +1 on PHP5.  There are a lot of things in the language that need
> to be cleaned up.  People here more familiar with other closed languages
> have gotten confused about things like case, underscores, haystack and
> needle, the way some array functions return an array and some modify the
> passed array.  There is just a lot of stuff like that.


I'm all for making the radical changes at 5.0, its just that it seems like 
Zeev is keen on a shortish timeframe for the new engine, whereas I suspect 
that tidying up the language will take quite a bit longer.

FWIW my vote is for us to make a concerted start on tidying the language with 
a realistic time frame of  1 year. If the new Zend engine is going to 
be ready much sooner than that, and it will only affect OO stuff and the 
business of accessing individual characters in strings, then that change 
should be to 4.1. If the engine is going to take a year, then we'll have a 
big pile of stuff to launch as 5.0

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] php 4.1 or php 5.0

[Phil Driscoll]

When I posted the other day about tidying up the language, I was hoping to 
get some kind of feel as to whether the new Zend engine would cause us to 
move to PHP 4.1 or to 5.0, since a move to 4.1 would allow us less 
opportunity to have a clean up than 5.0. (But moving to 4.1 would give us 
more time to think things through and get things done)

Does anyone have a view?
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Tidying up the language

[Phil Driscoll]

In the light of Zend's proposal for a version 2 of the Zend Engine, now is 
probably a good time to discuss whether we can and/or should use the 
opportunity to also tidy up the language along the lines we discussed on this 
list a few months ago namely:

Make function names case sensitive (and all lower case)
Rename functions to make them consistent
Address the order of arguments to functions so that needles and haystacks are 
consistent

(searching for 'renaming' in the QA archive will get you to most of the 
previous discussion)

A general concensus was not reached last time around, but I'm pretty sure 
that a majority of those who joined in the discussion thought it was a good 
idea to do at least some of the above.

My own thoughts on the timing of such an effort are that if the version 2 
Zend engine warrants a version 5 of PHP then we should make the effort and do 
something to synchronise with the release of the new engine, so that all the 
major changes happen together.

If the new engine only causes the PHP version number to go to 4.1 then I 
don't think we should introduce a language cleanup at this point, although I 
do think we should be working on it.

Rather than start near infinite threads on the nitty gritty details of what 
and how to change things, can we first establish a concensus on whether to 
have a go now or later, and see if we have enough people prepared to put in 
the hours.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Sablotron leaks

[Phil Driscoll]

On Sunday 24 June 2001 18:32, Rasmus Lerdorf wrote:
> > $xsl = join("", file("x.xsl"));
>
> Blah...  I see this a lot.  We should probably just relent and make a
> function that reads an entire file into a string.

Yes please!
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Phil Driscoll]

On Friday 22 June 2001 19:19, Liz wrote:
> Cool, thanks..
>
> I have a question, has the ISAPI version been stabalised enough that it
> wont crash works IIS 5 server??  Last time I put it on it screwed it over
> and my bosses got real mad..  But, I'd rather have it as ISAPI.. but.. I'll
> have my but kicked if I install it and it wipes out my server.
>
I can't speak for IIS5 but it is still unusable on my IIS4 box.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: FW: [PHP-QA] 4.0.6 Packaged!

[Phil Driscoll]

Liz

I've built the mssql dll for 4.06 and posted it at
http://www.dialsolutions.com/phil/php/php_mssql.dll

which along with the Windows Installer distribution at
http://www.dialsolutions.com/phil/php/php406-installer.exe

should give you a system you can test.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Phil Driscoll]

I've now packaged up the Windows Installer version for 4.0.6 (including crypt 
support) and posted it to
http://www.dialsolutions.com/phil/php/php406-installer.exe

It would be good it a few people could test it before Andi goes public with 
the release. It would be particularly useful to me if anyone who has IIS or 
PWS on NT4 or W2000 could test it as I have changed the bit that configures 
the webserver to avoid an annoying problem with an ocx control that the 
software needs.

Cheers

PS If anyone just needs it for testing the 4.0.6 binary and is afraid that 
the installation wizard might trash their carefully configured system, note 
that the exe is actually in zip format so you can get the bits out manually 
using winzip.
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: FW: [PHP-QA] 4.0.6 Packaged!

[Phil Driscoll]

On Thursday 21 June 2001 19:26, Liz wrote:
> I couldnt compile under win32, the 4.0.5 I had compiled fine, but this
> moans at everything, it wont find lib files, its barfing about byson.. 
> Anyone got a windows php.exe, php4ts.dll, with sql 7, and com support??

4.0.6 built without problems on my system. I can send you a cgi version 
without SQL7 support if you like, or if it is possible to build the SQL7 dll 
without having SQL AND someone tells me how to do it, I will make that as 
well.

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 Packaged!

[Phil Driscoll]

Just built 4.0.6 on NT4 and tested with my code under IIS. No problems found.
When I ran the test suite, there were a few errors, but I don't know whether 
or not these are expected on Win32. I've attached the output of the test.

Cheers
-- 
Phil Driscoll


Warning:  Undefined variable:  ext_found in ..\run-tests.php on line 307
Running tests in tests
==
dirname test (dirname.phpt)  ... failed


Warning:  Undefined variable:  ext_found in ..\run-tests.php on line 307
Running tests in tests/basic

Trivial "Hello World" test   ... passed
Simple POST Method test  ... passed
GET and POST Method combined ... passed
Two variables in POST data   ... passed
Three variables in POST data ... passed
Add 3 variables together and print result... passed
Multiply 3 variables and print result... passed
Divide 3 variables and print result  ... passed
Subtract 3 variables and print result... passed
Testing | and & operators... passed
Testing $argc and $argv handling ... passed


Warning:  Undefined variable:  ext_found in ..\run-tests.php on line 307
Running tests in tests/classes
==
Classes general test ... passed
Classes inheritance test ... passed


Warning:  Undefined variable:  ext_found in ..\run-tests.php on line 307
Running tests in tests/func
===
Strlen() function test   ... passed
Static variables in functions... passed
General function test... passed
General function test... passed
Testing register_shutdown_function() ... passed


Warning:  Undefined variable:  ext_found in ..\run-tests.php on line 307
Running tests in tests/lang
===
Simple If condition test ... passed
Simple While Loop Test   ... passed
Simple Switch Test   ... passed
Simple If/Else Test  ... passed
Simple If/ElseIf/Else Test   ... passed
Nested If/ElseIf/Else Test   ... passed
Function call with global and static variables   ... passed
Testing recursive function   ... passed
Testing function parameter passing   ... passed
Testing function parameter passing with a return value   ... passed
Testing nested functions ... passed
Testing stack after early function return... passed
Testing eval function... passed
Testing eval function inside user-defined function   ... passed
Testing include (015.phpt)   ... failed
Testing user-defined function in included file (016.phpt)... failed
Testing user-defined function falling out of an If into another  ... passed
eval() test  ... passed
eval() test  ... passed
Switch test 1... passed
Switch test 2... passed
Switch test 3... passed
Regression test (023.phpt)   ... failed
Looped regression test (may take a while) (024.phpt) ... failed
Mean recursion test  ... passed
Testing string scanner confirmance   ... passed
Testing do-while loop... passed
Testing calling user-level functions from C  ... passed
OO Bug Test (Bug #7515) (029.phpt)   ... failed
$this in constructor test... passed


Warning:  Undefined variable:  ext_found in ..\run-tests.php on line 307
Running tests in tests/strings
===

[PHP-DEV] Re: [PHP-QA] 4.0.6 Packaged!

[Phil Driscoll]

4.0.6 built ok on Suse 7.1.
Tested with my code (MySQL stuff mainly) and PhpMyAdmin.
No problems found.

Cheers

-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Phil Driscoll]

On Wednesday 20 June 2001 17:22, Andi Gutmans wrote:

> I suggest in order to get 4.0.6 out of the door I will package it today
> (the release), post it to php-dev&php-qa and we can announce it on Friday.

Sounds good. For the last release, in order to synchronise the release of the 
source and the two Windows binary versions, Zeev held off from posting the 
new version to the php.net downloads page until Daniel had brewed up the 
Windows binary zip and I had brewed up the Windows installer.  We emailed the 
stuff to Zeev and then he updated teh web site in one go.

Shall we do that with you this time?

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] 4.0.6RC4 out.

[Phil Driscoll]

Just built RC4 --with-apxs --with-mysql on Suze 7.1
Build went fine.
Tested with PhpMyAdmin 2.1.0 - works fine but got some new warning messages 
for deprecated mysql_db_query - which is fine.

Tested with all my own code (predominantly mysql related but accessing a wide 
range of core language features) with no problems.

My production machines are still NT - but not for long :) - so I can't do a 
sensible comparison on memory use.

I then built a cgi version and ran run-tests. The test output is attached. It 
failed on a few tests. I don't know whether these are real failures, or my 
incompetence - it's the first time I've run the tests on Linux.

Cheers
-- 
Phil Driscoll

X-Powered-By: PHP/4.0.6RC4
Content-type: text/html


Warning:  Undefined variable:  ext_found in run-tests.php on line 307
Running tests in /home/phil/php-4.0.6RC4/ext/crack/tests

[all 1 test(s) skipped]


Warning:  Undefined variable:  ext_found in run-tests.php on line 307
Running tests in /home/phil/php-4.0.6RC4/ext/ctype/tests

[all 2 test(s) skipped]


Warning:  Undefined variable:  ext_found in run-tests.php on line 307
Running tests in /home/phil/php-4.0.6RC4/ext/cybermut/tests
===
[all 1 test(s) skipped]


Warning:  Undefined variable:  ext_found in run-tests.php on line 307
Running tests in /home/phil/php-4.0.6RC4/ext/db/tests
=
[all 6 test(s) skipped]


Warning:  Undefined variable:  ext_found in run-tests.php on line 307
Running tests in /home/phil/php-4.0.6RC4/ext/gmp/tests
==
[all 2 test(s) skipped]


Warning:  Undefined variable:  ext_found in run-tests.php on line 307
Running tests in /home/phil/php-4.0.6RC4/ext/iconv/tests

[all 1 test(s) skipped]


Warning:  Undefined variable:  ext_found in run-tests.php on line 307
Running tests in /home/phil/php-4.0.6RC4/ext/interbase/tests

[all 6 test(s) skipped]


Warning:  Undefined variable:  ext_found in run-tests.php on line 307
Running tests in /home/phil/php-4.0.6RC4/ext/mcrypt/tests
=
[all 1 test(s) skipped]


Warning:  Undefined variable:  ext_found in run-tests.php on line 307
Running tests in /home/phil/php-4.0.6RC4/ext/session/tests
==
Session Object Serialization ... passed
session_unset() without any session  ... passed
Session Object Deserialization   ... passed
session_set_save_handler test (004.phpt) ... failed
Custom save handler, multiple session_start()s, complex data structu ... failed


Warning:  Undefined variable:  ext_found in run-tests.php on line 307
Running tests in /home/phil/php-4.0.6RC4/ext/skeleton/tests
===
[all 1 test(s) skipped]


Warning:  Undefined variable:  ext_found in run-tests.php on line 307
Running tests in /home/phil/php-4.0.6RC4/ext/standard/tests/file

File type functions  ... passed


Warning:  Undefined variable:  ext_found in run-tests.php on line 307
Running tests in /home/phil/php-4.0.6RC4/ext/standard/tests/math

Simple math tests... passed


Warning:  Undefined variable:  ext_found in run-tests.php on line 307
Running tests in /home/phil/php-4.0.6RC4/ext/standard/tests/general_functions
=
sprintf() function   ... passed
quoted_printable_decode() function test  ... passed
levenshtein() function test  ... passed
fgetcsv() with tab delimited fields (BUG #8258)  ... passed
is_scalar() function test... passed


Warning:  Undefined variable:  ext_found in run-tests.php on line 307
Running tests in /home/phil/php-4.0.6RC4/ext/standard/tests/reg
===
RegReplace test 1... passed
RegReplace test 2... passed
ereg_replace single-quote test   ... passed
simple ereg test ... passed
Test Regular expression regi

[PHP-DEV] Bug #11042: magic_quotes_runtime() value not reality

[phil]

From: [EMAIL PROTECTED]
Operating system: Solaris 2.x / 7 / 7
PHP version:  4.0.5
PHP Bug Type: *General Issues
Bug description:  magic_quotes_runtime() value not reality

This issue has been duplicated in 4.0.5 and 4.0.4pl1.  We've not tried to go further 
back.

We have several small HTML forms applications that make use of PHPLIB's template 
feature.  Sometimes when HTML is generated, things are fine.  Other times, it's all 
horked up because there are back-slashes in the HTML output.  We've tracked the root 
cause of this issue to PHP's setting of magic_quotes_runtime().

We have it configured for "Off" but sometimes this function value is 1, other times it 
is 0.  We can insert:

print "magic rt = " . magic_quotes_runtime() . "";

into our application ... sometimes we'll see that the value is 1, other times 0.  Just 
clicking refresh seems to yield a seemly random result.

We've worked around this issue by adding

ini_set("magic_quotes_runtime", 0);

at the top of our code ... but this behavior can't be expected.  Or are we missing 
something?

Thanx for your time in looking into this -- you have a great environment for web 
programming.



-- 
Edit Bug report at: http://bugs.php.net/?id=11042&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0.6RC1 ready for testing

[Phil Driscoll]

> >Please everyone take sometime to make sure this is release worthy :)
Would someone be kind enough to post a Windows binary somewhere - I have a 
new machine and have not installed any dev tools and no doubt 4.0.6 will be 
released before I get everything working :-)

I'm sure other QAers will benefit anyway.

Cheers
-- 
Phil Driscoll


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] RE: [PHP-DEV] Re: [PHP-QA] Modifications to Windows Readme file

[Phil Driscoll]

On Friday 11 May 2001 23:26, Richard Lynch wrote:
> If you ignore it, you'll continue the problem:  People attempt to install
> PHP with PWS on Win95/98 and get frustrated, and have to dig all over
> creation to find install instructions that should have been in the PHP
> release.

What I'm suggesting that we ignore is the fact that PWS4 on NTWS might for 
legacy reasons look at the registry - although I have no evidence that it 
does other than the old PHP installation instructions.

The new installation instructions I've submitted to the phpdoc team give 
instructions on fiddling with the registry for W9x/ME users, and updating the 
IIS metabase for IIS4+/PWS4+ users on NT server, NTWS and W2K.

In other words, I believe that the new instructions are both consistent and 
correct :)

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Is this still true?

[Phil Driscoll]

>I thought that PHP was available as a ISAPI & NSAPI plug-in already?

Partly true. Yes ISAPI and NSAPI modules do exist. I have no experience of
the NSAPI module, however the ISAPI module is, sadly - and despite a lot of
hard work, still far from production quality.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] RE: [PHP-DEV] Re: [PHP-QA] Modifications to Windows Readme file

[Phil Driscoll]

>As I was aware the PWS on NT4 did use registry stuff, as the management
>console sucks.  But, its been a long time since I looked at one.
To the best of my knowledge, it used to when it was based on IIS3 (and was
essentially the same thing currently shipped as PWS for 9x/ME) but the
current PWS for NTWS is essentially IIS4.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] RE: [PHP-DEV] Re: [PHP-QA] Modifications to Windows Readme file

[Phil Driscoll]

I'm in the middle of sorting out the windows installation instructions for
the manual and the readme file for the windows distribution. What I thought
would be a quick job, as usual, is much more complicated than I thought. The
readme.txt, install.txt and the manual all contradict each other, and all
are wrong in various places :(

Anyway, I'm well on with the job, but I have an issue with the instructions
on installing PHP with PWS on NT Workstation. All the instructions
everywhere talk about editing the registry, but as far as I am aware, PWS on
NTWS is not in the least bit interested in the registry - it uses the IIS
metabase just the same as IIS 4 and above. The windows installer certainly
edits the metabase rather than the registry when doing an install of PWS on
NTWS, and that works fine. As far as I'm concerned, the instructions for
installing PHP on PWS/NTWS should be the same as for installing with IIS/NT
Server.

Does anyone know something I don't on this issue, or is it ok for me to go
ahead and change the instructions accordingly?

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] RE: [PHP-DEV] Re: [PHP-QA] Modifications to Windows Readme file

[Phil Driscoll]

>Does it suck that bad?

No - it doesn't suck at all!
It's just that James's suggestion that we update the installation chapter of
the manual and generate the installation noted from that is so eminently
sensible, that it would be foolish to do otherwise - which sadly means that
the efforts both you and I did earlier will be consigned forever to languish
in the 'deleted items' folder :)

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] RE: [PHP-DEV] Re: [PHP-QA] Modifications to Windows Readme file

[Phil Driscoll]

>then please merge the install.txt in there, as it's currently somewhat 
>incomplete

I will attempt to do that this afternoon.

Cheers
-- 
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Modifications to Windows Readme file

[Phil Driscoll]

>an html file would be certainly good, so you're encouraged to convert it :)
I'll attempt to merge readme.txt and install.txt into a new readme.html
tomorrow, work pressures permitting, unless anyone else wants to have a go
before then.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Modifications to Windows Readme file

[Phil Driscoll]

>In the bit where you say assign php4isapi.dll to the .php extension woudlnt
it
>be beneficial to say for the CGI version use php.exe etc.. and for the
ISAPI
>version use the DLL?
Yes it should. I did do this a while ago, and I thought that that was in
this file, but it is in fact in the install.txt file. That'll teach me to
read things more carefully!

Damn!

Perhaps I should combine both files into just the one - but I'm out of time
for today.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Modifications to Windows Readme file

[Phil Driscoll]

There is a separate file called install.txt which covers installation on a
wider range of servers.

Ideally there would be one document - I was just soaking up a spare 10
minutes to improve things a bit!

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Modifications to Windows Readme file

[Phil Driscoll]

The attached file is a modified version of the README.txt file for the
Windows distribution.

Changes I've made are as follows:

I've changed the wording of the opening paragraph about the ISAPI module to
make it clear that users really are likely to have a bad time with the ISAPI
module stability.

I've added a section at the end on how to fix common problems which should
save a good bit of list traffic.

If anyone has any comments, changes or suggestions please let me know, or if
people are happy with the changes, would someone be kind enough to commit
the file to CVS - I'm in the middle of setting up my new computer and don't
yet have a working CVS client up and running.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org




PHP 4.0 - Win32 Distribution



Note


PHP 4.0 for Windows comes in two flavours - a CGI executable (php.exe), and an
ISAPI module (php4isapi.dll).  The latter is new to PHP 4.0, and provides
significantly improved performance and some new functionality.  However,
please note that the ISAPI module is *NOT* yet considered to be production
quality and you are likely to encounter serious reliability problems especially on
platforms older than W2K - in particular you may witness a lot of server 500 errors
and suffer from other server modules such as ASP also failing. The reason for this
is that the PHP ISAPI module uses the thread-safe version of the PHP code, which is
completely new to PHP 4.0, and has not yet been tested and pounded enough to be
considered completely stable, and there are actually a few known bugs.
On the other hand, some people have reported very good results with the ISAPI
module, even though we're not aware of anyone actually running it on a production
site.  In short - your mileage may vary;  If you need absolute stability, trade the
performance of the ISAPI module with the stability of the CGI executable.


Requirements


- Windows 95 or later, Windows NT 4.0 or later
- ISAPI 4.0 compliant Web server required for ISAPI module (tested on IIS 4.0,
  PWS 4.0 IIS 5.0).  IIS 3.0 is *NOT* supported;  You should download and
  install the Windows NT 4.0 Option Pack with IIS 4.0 if you want native PHP
  support.
- Windows 95 requires the DCOM update, freely available from:
http://download.microsoft.com/msdownload/dcom/95/x86/en/dcom95.exe


Support
---

For questions and help with PHP under Windows, your best bet would be the
PHP-Windows mailing list ([EMAIL PROTECTED]).  To subscribe, send
an empty message to [EMAIL PROTECTED]


Installation


Unlike PHP 3, PHP 4 is divided into several components;  Even when you use
PHP in its CGI mode, php.exe is no longer a standalone executable, and relies
on external DLLs for execution.  For this reason, if you install php.exe as
a handler for your web server, you must make sure that the DLLs in the
distribution exist in a directory that is in the Windows PATH.  The easiest
way to do it is to copy these DLLs to your SYSTEM (Windows 9x) or SYSTEM32
(Windows NT) directory, which is under your Windows directory.
The DLLs that need to be copied are MSVCRT.DLL (it may already exist in there)
and PHP4TS.DLL.

Installation Notes for IIS 4.0 and 5.0
--

- Install the DLLs as mentioned above.
- If you wish to change any defaults, copy either the php.ini-dist or
  php.ini-optimized files into your Windows directory, and rename it to
  'php.ini'.  You can then modify any of the directives inside it.
- Start the Microsoft Management Console (may appear as
  'Internet Services Manager', either in your Windows NT 4.0 Option Pack
  branch or the Control Panel->Administrative Tools under Windows 2000).
- Right click on your Web server node (will most probably appear as 'Default
  Web Server'), and select 'Properties'.
- If you don't want to perform HTTP Authentication using PHP, you can (and
  should) skip this step.  Under 'ISAPI Filters', add a new ISAPI filter.
  Use 'PHP' as the filter name, and supply a path to the php4isapi.dll that
  is included in the distribution.
- Under 'Home Directory', click on the 'Configuration' button.  Add a new
  entry to the Application Mappings;  Use the path the php4isapi.dll as the
  Executable, supply .php as the extension, leave 'Method exclusions', blank,
  and check the Script engine checkbox.
- Stop IIS completely (you would have to stop the IIS Administration service
  for that - stopping it through the Management Console isn't good enough;
  You can do it by typing 'net stop iisadmin' on a command prompt).
- Start IIS again (you can do it by typing 'net start w3svc' on a command
  prompt).
- Put a .php file under your Web server's document root and check if it works!

Installation Note

[PHP-DEV] Bug #10739 Updated: Zlib compile fails

[phil . cohen]

ID: 10739
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Compile Failure
Operating system: Red Hat 7.1
PHP Version: 4.0.5
Description: Zlib compile fails

My compile options follow:

./configure \
--prefix=/usr/local/php \
--disable-debug \
--enable-shared \
--enable-inline-optimization \
--with-apxs=/usr/sbin/apxs \
--with-gd \
--with-jpeg-dir=/usr \
--with-png \
--with-zlib \
--with-db2 \
--with-db3 \
--with-gdbm \
--disable-debug \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-track-vars \
--enable-yp \
--enable-ftp \
--enable-wddx \
--with-mysql \
--with-xml \
--disable-short-tags \
--enable-trans-sid \
--with-imap \
--with-mcrypt \ 
--with-mhash \
--enable-bcmath \
--with-ttf \
--with-t1lib \ 
--with-pgsql \
--with-ldap

Previous Comments:
---

[2001-05-08 18:32:59] [EMAIL PROTECTED]
Zlib fails to compile even though it is properly installed. 

configure: error: Zlib module requires zlib >= 1.0.9.

[root@websmith php-4.0.5]# rpm -qa |  grep zlib
zlib-1.1.3-22
zlib-devel-1.1.3-22

Bug 8575 says;
[2001-04-10 09:45:37] [EMAIL PROTECTED]

No feedback. If this happens with soon to be released PHP 4.0.5 too, reopen this bug
report.

--Jani

---


Full Bug description available at: http://bugs.php.net/?id=10739


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10739: Zlib compile fails

[phil . cohen]

From: [EMAIL PROTECTED]
Operating system: Red Hat 7.1
PHP version:  4.0.5
PHP Bug Type: Compile Failure
Bug description:  Zlib compile fails

Zlib fails to compile even though it is properly installed. 

configure: error: Zlib module requires zlib >= 1.0.9.

[root@websmith php-4.0.5]# rpm -qa |  grep zlib
zlib-1.1.3-22
zlib-devel-1.1.3-22

Bug 8575 says;
[2001-04-10 09:45:37] [EMAIL PROTECTED]

No feedback. If this happens with soon to be released PHP 4.0.5 too, reopen this bug
report.

--Jani


-- 
Edit Bug report at: http://bugs.php.net/?id=10739&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #10684 Updated: Installation Problem

[Phil Driscoll]

Sorry for direct posting - I can't get onto the bugs database at the moment.

Copying php.ini is the last thing the installer does before running the bit
that configures IIS - and this is the thing that uses MSCOMCTL. I suspect
that your registration of that module failed or you have a dodgy module - is
the Win98 dir a standard feature of W2K or perhaps something left over from
an old Win98 installation - I'm guessing here but maybe the MSCOMCTL that
you have is the wrong version for W2K?

In any event, php will be installed ok on your system, all you need to do is
forget the automatic IIS configuration and manually configure the php script
mapping in the Microsoft Mamnagement Console as per the installation notes.

Good luck!
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process

[Phil Driscoll]

Andi wrote:
>That brings me to more current events. I'd like to roll an RC1 for 4.0.6
>pretty soon (Saturday?).

I don't want to slow things down here, and if Saturday can be achieved, all
well and good, but we perhaps ought to have a strong guideline that, say, 1
weeks warning of an impending RC is given. That will give everyone time to
either get their important stuff in, or argue for a delay, and there will be
a lower probability of people wanting to stick stuff in other than bugfixes
after RC1.

If we can't have a firm rule that only bug fixes go in after RC1, can we at
least agree that that is the guideline in upper case bold 72 point flashing
red and green text?

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RE: [PHP-QA] 4.0.6

[Phil Driscoll]

I think the key thing with RCs was touched on by James - we need to be
complete bastards as to what's allowed in after RC1 otherwise every RC is
really RC1, however human nature and available time means RCN (where N>1)
gets less testing than RC1.

Can we set karma levels on the RC branch such that only a very restricted
set of people can commit, and anyone who wants to submit a fix has to argue
and explain to get it in, and anyone who wants to commit a feature can be
sent away with a flea in their ear.

Also for Windows testing it would help if someone who understands the test
system posts a step by step hand holding list of things to do to make it
work on Windows - it will then get used much more.

Also on the test suite, it always worries me that it tests the executable
rather than via the web server/browser and so must miss out on testing loads
of functionality as well as testing in the wrong environment. Would it be
possible to modify the tests so that optionally they can be run via a
browser (even if it means clicking on a load of 'next' buttons). Test output
could still be spooled to a single file so that there is a central pool of
results which can be reported back to the list.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] RC8

[Phil Driscoll]

Just built RC8 without incident on NT4 SP6 and Suse 7.1.
Tested on NT with phpMyAdmin, phorum and all my own code - all fine (as
usual!).
Only done a phpinfo() on Linux - but it worked ok :)
Got to go now, but will test more later.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: 4.0.5: Merge Request

[Phil Driscoll]

No new ideas here, just clarification of what I think we should do with the
current technology available.

As far as I remember, someone is rewriting the bug db (or maybe I was
dreaming?). If so, then a new 'importance' field can be added to rank the
bug as showstopper, important etc. The fact that the bug report gets posted
to the dev list with 'showstopper' status should be enough to alert people
to either fix it, or argue for its demotion to a less severe status. The
rule should be that showstoppers are never allowed in a release.

Prior to the bug database getting this feature, the list can be manually
maintained on the qa list.

A strongly agree with Liz that we MUST become strict about no new features
going into the release branch after RC1. Maybe this would be helped by a
regular RC cycle - maybe once every two months. Then everyone will know when
RC1 is due and if they want features in it, then they know what date they
have to hit to get it there. And if they miss the date, they know it's only
two months before it will get into a release.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RC7 is out

[Phil Driscoll]

Windows testers please note (and apologies to those who think I'm teaching
granny to suck eggs):

Just to avoid a potential cockup with the Win32 release, be aware that the
RC7 source builds a debug version of PHP by default on windows - we ought to
be testing (and releasing!) the release_ts_inline version - just set the
correct active configuration in the build menu.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Phil Driscoll]

Sterling wrote:

>Well, I don't know how valid that argument (dialup) really is.  I
>currently use a dial up connection (56k) and I'm fine with php (it takes
>at most 20 minutes to download and I can do other things while php is
>downloading).

For sure it's an argument that gets weaker as time goes on and bandwidths
increase :)

I think my main point is valid though. Placing popular extensions in one
place and unpopular ones in another draws an arbitrary line in the sand
which makes it impossible to intuitively guess where things should be. The
only way for this to be handled elegantly is for all extensions to live in
the same place.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Phil Driscoll]

The business of moving extensions to PEAR appeals to me as I think that PHP
currently feels too big - especially from the point of view of the potential
new user with a dial up connection, who may well look elsewhere for
something smaller. However, I think the idea of moving some extensions to
PEAR and leaving others alone will produce a situation where 'knowing' where
to find an extension is not intuitive.

The two solutions to this which spring to mind are:

ALL extensions are in PEAR, and a download tool allows easy selection of
extensions, perhaps with a 'most common options' button to include the
favourite extensions.

As above except that the most common extensions are somehow promoted fom
being extensions into the core of PHP.

Maybe neither of these are ideal, but I just think we need to make sure that
whatever happens in logical and intuitive.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]