[PHP-DEV] PHP 4.0 Bug #8792: Web browser hangs when I try to access a .php file
From: [EMAIL PROTECTED]
Operating system: Windows \'95
PHP version: 4.0.4pl1
PHP Bug Type: Reproduceable crash
Bug description: Web browser hangs when I try to access a .php file
I installed PHP with Apache Server 1.3 on my Windows '95 machine. I checked to make
sure all the needed entries were present in the configuration, according to the
installation instruction (MIME type, Script Alias, etc.), and that all the required
DLLs were in the windows/system directory, and I get no output when I try to run a
.php script. When I look at the Windows '95 task list, I see that there is a Php task
stuck in it, so my belief is that php is locking up. Do you know what might be
causing this? I'll include the php.ini file.
[PHP]
;;;
; About this file ;
;;;
; This file controls many aspects of PHP's behavior. In order for PHP to
; read it, it must be named 'php.ini'. PHP looks for it in the current
; working directory, in the path designated by the environment variable
; PHPRC, and in the path that was defined in compile time (in that order).
; Under Windows, the compile-time path is the Windows directory. The
; path in which the php.ini file is looked for can be overriden using
; the -c argument in command line mode.
;
; The syntax of the file is extremely simple. Whitespace and Lines
; beginning with a semicolon are silently ignored (as you probably guessed).
; Section headers (e.g. [Foo]) are also silently ignored, even though
; they might mean something in the future.
;
; Directives are specified using the following syntax:
; directive = value
; Directive names are *case sensitive* - foo=bar is different from FOO=bar.
;
; The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one
; of the INI constants (On, Off, True, False, Yes, No and None) or an expression
; (e.g. E_ALL ~E_NOTICE), or a quoted string ("foo").
;
; Expressions in the INI file are limited to bitwise operators and parentheses:
; | bitwise OR
; bitwise AND
; ~ bitwise NOT
; ! boolean NOT
;
; Boolean flags can be turned on using the values 1, On, True or Yes.
; They can be turned off using the values 0, Off, False or No.
;
; An empty string can be denoted by simply not writing anything after the equal
; sign, or by using the None keyword:
;
; foo = ; sets foo to an empty string
; foo = none ; sets foo to an empty string
; foo = "none"; sets foo to the string 'none'
;
; If you use constants in your value, and these constants belong to a dynamically
; loaded extension (either a PHP extension or a Zend extension), you may only
; use these constants *after* the line that loads the extension.
;
; All the values in the php.ini-dist file correspond to the builtin
; defaults (that is, if no php.ini is used, or if you delete these lines,
; the builtin defaults will be identical).
; Language Options ;
engine = On ; Enable the PHP scripting language engine
under Apache
short_open_tag = On ; allow the ? tag. otherwise, only ?php and
script tags are recognized.
asp_tags= Off ; allow ASP-style % % tags
precision = 14 ; number of significant digits displayed in
floating point numbers
y2k_compliance = Off ; whether to be year 2000 compliant (will cause
problems with non y2k compliant browsers)
output_buffering= Off ; Output buffering allows you to send header lines
(including cookies)
; even after you send body
content, in the price of slowing PHP's
; output layer a bit.
; You can enable output
buffering by in runtime by calling the output
; buffering functions, or
enable output buffering for all files
; by setting this directive to
On.
implicit_flush = Off ; Implicit flush tells PHP to tell the output layer to
flush itself
; automatically after every
output block. This is equivalent to
; calling the PHP function
flush() after each and every call to print()
; or echo() and each and every
HTML block.
; Turning this option on has
serious performance implications, and
; is generally recommended for
debugging purposes only.
allow_call_time_pass_reference = On; whether to enable the
[PHP-DEV] PHP 4.0 Bug #8792 Updated: Web browser hangs when I try to access a .php file
ID: 8792
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproduceable crash
Description: Web browser hangs when I try to access a .php file
This is the error I get in the error.log file when I try to access a .php script and
the browser hangs.
[Thu Jan 18 13:50:34 2001] [error] [client 207.208.143.94] Premature end of script
headers: c:/php/php.exe
Previous Comments:
---
[2001-01-18 13:54:26] [EMAIL PROTECTED]
I installed PHP with Apache Server 1.3 on my Windows '95 machine. I checked to make
sure all the needed entries were present in the configuration, according to the
installation instruction (MIME type, Script Alias, etc.), and that all the required
DLLs were in the windows/system directory, and I get no output when I try to run a
.php script. When I look at the Windows '95 task list, I see that there is a Php task
stuck in it, so my belief is that php is locking up. Do you know what might be
causing this? I'll include the php.ini file.
[PHP]
;;;
; About this file ;
;;;
; This file controls many aspects of PHP's behavior. In order for PHP to
; read it, it must be named 'php.ini'. PHP looks for it in the current
; working directory, in the path designated by the environment variable
; PHPRC, and in the path that was defined in compile time (in that order).
; Under Windows, the compile-time path is the Windows directory. The
; path in which the php.ini file is looked for can be overriden using
; the -c argument in command line mode.
;
; The syntax of the file is extremely simple. Whitespace and Lines
; beginning with a semicolon are silently ignored (as you probably guessed).
; Section headers (e.g. [Foo]) are also silently ignored, even though
; they might mean something in the future.
;
; Directives are specified using the following syntax:
; directive = value
; Directive names are *case sensitive* - foo=bar is different from FOO=bar.
;
; The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one
; of the INI constants (On, Off, True, False, Yes, No and None) or an expression
; (e.g. E_ALL ~E_NOTICE), or a quoted string ("foo").
;
; Expressions in the INI file are limited to bitwise operators and parentheses:
; | bitwise OR
; bitwise AND
; ~ bitwise NOT
; ! boolean NOT
;
; Boolean flags can be turned on using the values 1, On, True or Yes.
; They can be turned off using the values 0, Off, False or No.
;
; An empty string can be denoted by simply not writing anything after the equal
; sign, or by using the None keyword:
;
; foo = ; sets foo to an empty string
; foo = none ; sets foo to an empty string
; foo = "none"; sets foo to the string 'none'
;
; If you use constants in your value, and these constants belong to a dynamically
; loaded extension (either a PHP extension or a Zend extension), you may only
; use these constants *after* the line that loads the extension.
;
; All the values in the php.ini-dist file correspond to the builtin
; defaults (that is, if no php.ini is used, or if you delete these lines,
; the builtin defaults will be identical).
; Language Options ;
engine = On ; Enable the PHP scripting language engine
under Apache
short_open_tag = On ; allow the ? tag. otherwise, only ?php and
script tags are recognized.
asp_tags= Off ; allow ASP-style % % tags
precision = 14 ; number of significant digits displayed in
floating point numbers
y2k_compliance = Off ; whether to be year 2000 compliant (will cause
problems with non y2k compliant browsers)
output_buffering= Off ; Output buffering allows you to send header lines
(including cookies)
; even after you send body
content, in the price of slowing PHP's
; output layer a bit.
; You can enable output
buffering by in runtime by calling the output
; buffering functions, or
enable output buffering for all files
; by setting this directive to
On.
implicit_flush = Off ; Implicit flush tells PHP to tell the output layer to
flush itself
; automatically after every
output block. This is equivalent to
; calling the PHP function
flush() after each and every call to print()
[PHP-DEV] PHP 4.0 Bug #9481 Updated: Passing out class property by reference problem
ID: 9481
User Update by: [EMAIL PROTECTED]
Status: Closed
Bug Type: Scripting Engine problem
Description: Passing out class property by reference problem
You can get round the above problem somewhat using:
function foo ($aVar)
{
$aVar['value'] = $GLOBALS["baz"];
}
foo($bar);
$bar['value'] is now a reference to $GLOBALS["baz"] as you would expect.
Previous Comments:
---
[2001-03-08 06:58:36] [EMAIL PROTECTED]
This is not a bug. Please read the "References explained"
part in the manual. When you have $a = $b and you do $a =
$c, you don't make a and b be references to c, you make only
$a bound to $c and unbound from $b. So when you did $refObj
= $this-sValue
$refObj stopped being reference to call parameter and
became reference to $this-sValue. There's no real way to
make "other" referenced value to be rebound to some new value.
---
[2001-02-27 10:42:34] [EMAIL PROTECTED]
?
function xmpdump($xValue, $sLabel="")
{
echo "$sLabelxmp";
var_dump($xValue);
echo "/xmp";
}
class test
{
var $sValue;
var $Count = 0;
function getTest($refObj)
{
if (isset($this-sValue))
{
$refObj = $this-sValue;
xmpdump($refObj, "Reference before being passed
back");
return;
}
else
{
$refObj = "phil".$this-Count;
$this-Count++;
$this-sValue = $refObj;
xmpdump($refObj, "Value before being passed back");
return;
}
}
}
$tst = new test();
$tst-getTest($tstObj0);
xmpdump($tstObj0, "Value after being passed back");
$tst-getTest($tstObj1);
xmpdump($tstObj1, "Refence after being passed back");
?
The dump of $tstObj1 is NULL, despite the dump of $refObj immediately before it in the
function working correctly.
---
Full Bug description available at: http://bugs.php.net/?id=9481
--
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] Bug #11042: magic_quotes_runtime() value not reality
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() . br; 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=11042edit=1 -- 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.4pl1 RC2 rolled
The lists are fine. Sorry - there must be some hiccup between the lists and Demon in the UK then. I'm sure the messages will come flooding through soon. 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] PHP 4.0.4 patchlevel 1 released
i uploaded a package at http://www.php4win.com/download/php-4.0.4pl1-Win32.zip maybe phil can up it when he's uploading the installer, i'm out of karma :) Sorry about the delayed response - I've been away at an exhibition and I'm still not getting emails from any of the php lists - my ISP reckons that the DNS machines for php.net are not giving authoritative responses. I've given Sascha the details so hopefully something can be sorted out. I'm on the case now, so the full installation ZIP and the Windows installer should be up and running within a couple of hours. 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] PHP 4.0.4 patchlevel 1 released
Could you guys confirm that this problem no longer exists? Yes - mail now coming in in torrents! 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 4.0 Bug #8071 Updated: quotes being added with readfile()
Upgraded to 4.0.4pl1, tested with a file that gave me trouble before.
Problem has been fixed. Thanks very much for looking after it!
Phil
On Tue, Jan 30, 2001 at 09:24:16AM -, Bug Database wrote:
ID: 8071
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: *Session related
Assigned To:
Comments:
This should be fixed in PHP 4.0.4pl1 (or at least in the
latest CVS, try a snapshot from http://snaps.php.net/ )
--Jani
Previous Comments:
---
[2000-12-11 10:35:48] [EMAIL PROTECTED]
The user is using trans-sid feature.
Could you please give example of any file where it happens?
---
[2000-12-11 05:41:11] [EMAIL PROTECTED]
Do you use trans-sid feature?
---
[2000-12-01 16:34:52] [EMAIL PROTECTED]
PHP seems to be adding quotes after "=" (equal signs) when putting a binary file
through to the browser via readfile().
A snippet of the code doing this:
// Send the file. Note that PHP automatically sends the
// private cache directives as this is part of a session.
$size = filesize("$xferdir-path/$dload");
header("Content-Type: $type");
header("Content-Length: $size");
// detect any gzip'd files and set the content encoding
// header accordingly
if (preg_match('/.gz$/', $file))
header ("Content-Encoding: gzip");
// disable magic quotes so they don't interfere with the
// file being sent.
// if (get_magic_quotes_runtime())
set_magic_quotes_runtime(0);
// dump the file to the browser
if (readfile("$xferdir-path/$dload") == $size) {
// if the file is fully downloaded
// add a line to the sslxfer log
log_xfer("$xferdir-path/$dload", "down");
}
The script is called as "dload.php/filename" and then sends the given file to the
user. I'll check with our legal dept (blech) on Monday and see if I can make the
original and modified files available.
---
Full Bug description available at: http://bugs.php.net/?id=8071
--
Phil Steinke[EMAIL PROTECTED]
Network Ops (UNIX) 613-530-2002
Canadian Microelectronics Corporationhttp://www.cmc.ca/
--
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: Fail to make PHP with zeus
On Thu, Feb 01, 2001 at 05:24:46PM +0800, Jacky Chou wrote: I was compiling PHP 4.0.4pl1 with Zeus in Solaris 8 Sparc system but I got an error: zend_operators.h:84: implicit declaration of function `int finite(...)' This appears to be a problem with PHP's configure script. I ran into the same thing. You have to edit the php-4.0.4pl1/main/php_config.h file, and change /* #undef HAVE_IEEEFP_H */ to #define HAVE_IEEEFP_H 1 It should then be able to compile. -- Phil Steinke[EMAIL PROTECTED] Network Ops (UNIX) 613-530-2002 Canadian Microelectronics Corporationhttp://www.cmc.ca/ -- 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] Time for 4.0.5?
any other suggestions? There has been talk on here, or maybe on the QA list about a web page where you tick the items you want, and just download the necessary components. Maybe this was just in the context of PEAR - I can't remember. Anyway, is anyone working on this? It seems to be a good solution to me (but then I don't understand how the config and .m4 stuff works!). 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] ctype function (re?)naming
RFC: what should their names be in 4.0.5? ( ) stay with ctype_alpha() ... (X) switch to ctype_isalpha() ... ( ) switch to ctype_isalpha() ... and have ctype_alpha() aliases ( ) switch to ctype_is_alpha() ... ( ) switch to ctype_is_alpha() ... and have ctype_alpha() aliases (X) have an alias if isalpha() A heated argument seems to be developing, which IMHO makes no sense when we are discussing a tiny corner of the language. Yes, function names should be consistent, however because the current namespace is such a mess it is impossibly to argue the toss on this issue because all we can do is make the function name compatible with one (or more) of a range of inconsistent 'standards' throughout the language. It HAS to be time for a big tidy up, as it is clearly impossible to 'do the right thing' under current circumstances. 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] ctype function (re?)naming
Oops (X) have an alias if isalpha() should have read (X) have an alias of isalpha() and it is impossibly to argue should have read it is impossible to argue I appear to have lost my grip on the English language this morning, so who am I to comment on the PHP language :) -- 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] Re: [PHP-DEV] ctype function (re?)naming
Ron - whose postings I normally agree with :-) - wrote: Ignoring case, the extension count, and the possible naming styles, is as follows: word_word_word: 65 wordwordword: 24 word_wordword: 21 Some extensions use more than one style, but the one most often used is word_word_word. Many functions fit into word_word, which is not affected one way or another by observing the most common thread in naming. The standard seems to already be in place. I'll grant that you have shown that word_word_word is the most popular format in use, which gives weight to the argument that the underscore should be how we do it, but this falls far short of a standard because those words are not obeying sensible rules. We have a random mix of ext_verb_noun and ext_noun_verb, a mixture of verbs which do the same job, and a motley assortment of other subtleties on the end of or inserted into function names. That's before we start looking at the order of the arguments. The fact is (with no blame attributed anywhere - the way the software has evolved has made this more or less inevitable) that the namespace is grossly self inconsistent. I have to look at the manual much more often than I do with other languages I use. The business of whether to use underscores or studly caps is just a matter of personal preference, and it is MUCH more important to get the language consistent than to bicker about that kind of detail (which, in extremis, could even be made configurable, or multiple options supported if a consensus could not be reached). I know that Zak has been doing some experiments along these lines, but has also been busy on other projects. Any news to report Zak? 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] ctype function (re?)naming
Prodigious work Zak - well done. This certainly represents a useful initial tidy up. It doesn't break anything and cures many of the 'bad offenders'. In looking through the unchanged function names, the one that screamed 'I am wrong' most loudly was 'velocis_off_autocommit' which appears to set new standards in unusual word order :) As you may have gathered from my previous posts on the subject, I want to aim much higher than this, but as I gather from everyone else's posts, I'm in a small minority. I see no reason for the syntax of PHP being any less than 'very good indeed', so if anyone else is in that minority, without detracting from the work that Zak has proposed, can we keep this discussion thread alive because I'm sure that there must be a way of bolting a clean version of the language onto the existing engine, and surely PHP 5.0 is the landmark for it's introduction. 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] PHP as ISAPI module crashes but...
I'm a keen as you are for the PHP ISAPI module to work reliably, but before
we start sorting out the extension modules, we need to sort out the core
itself. For me (on my NT4/IIS4/SP6 setup), php 'straight out of the box'
falls over with server 500 errors on the simplest of scripts - even with
only a single request being made to the server (which may rule out the
problem being anything to do with thread safety?).
Perhaps we could get together a few simple and a few more complicated
scripts and try them on a range of machines and see if we can start to make
any conclusions.
My suggestions for starters are:
---
?php
echo('hello');
?
---
?php
phpinfo();
?
(which will probably start up simultaneous threads at it fetches the images)
---
?php
/*something simple which takes a long time so that we get a chance to fire
off multiple simultaneous requests to it*/
?
---
Any other thoughts?
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] PHP as ISAPI module crashes but...
Paco wrote: are you trying with 4.0.4pl1? Try, please. I had the same problems with previous Yes, I've been using 4.0.4pl1 since day '0', and it 'reliably' goes wrong for me. Are you using NT4 or W2K? 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] 4.0.5RC1 packaged
I've just put 4.0.5RC1 (the Windows binaries posted by James Moore) through their paces on N4 SP6 IIS CGI. I've tried all my stuff (general language stuff + MySQL) plus phpMyAdmin and Phorum. Everything tested works fine. 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] feature request
My earlier post to the list doesn't seem to have arrived yet, so here it is again. You'll note from the posting that I'm not keen on the patch staying in. There are considerable efforts being made by several of us on the QA team trying to make the language more orthogonal, and this kind of ad hoc addition really doesn't help. That is the only thing that I see of any real use as well. I was just humoring Andi and his idea that we would soon be requesting that feature of knowing which one failed the test. I was really voting no for the original feature - just returning true or false - unless it can be shown (and implemented) that iswhatever(multiple args) will work sensibly across the board, and that implementing iswhatever(multiple args) does not waste the function namespace for a new feature - e.g. loads of php functions take optional extra arguments to modify their behaviour, but once iswhatever gained the multi argument functionality described, it would be impossible to extend the functionality in this way. Cheers, and apologies for such a long sentence -- 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] feature request
Zeev said: Define 'change their behavior' though? 'change their behavior' === 'change their behavior' in a subtle way :) Almost all SQL functions take an optional argument which is the link id. That is by design, and doesn't really mean anything here, I'm not saying it does mean anything here - I cannot think of a sensible extra argument to modify isset. What I am saying is that if I were not in the middle of building a ceiling for my bathroom, I'm sure I could find either an existing issomething or ext_issomething function which already uses an optional extra argument, or at least, could use one to good effect. Torben has picked up on what I'm getting at - all 'is' functions should work the same way - this (IMHO) is much more important than a bit of useful ad-hoc functionality. If it turns out that we can do this trick to all 'is' functions without any problems, then great - do it, but do it to all of them. 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] feature request
That is the only thing that I see of any real use as well. I was just humoring Andi and his idea that we would soon be requesting that feature of knowing which one failed the test. I was really voting no for the original feature - just returning true or false - unless it can be shown (and implemented) that iswhatever(multiple args) will work sensibly across the board, and that implementing iswhatever(multiple args) does not waste the function namespace for a new feature - e.g. loads of php functions take optional extra arguments to modify their behaviour, but once iswhatever gained the multi argument functionality described, it would be impossible to extend the functionality in this way. Cheers, and apologies for such a long sentence! -- 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] builtin functions / constructs
it should be even more save to hardcode them in PHP itself sticking nose in where it's not wanted ...or better still not to have language constructs at all so that everything that looks like a function also works like a function. /sticking nose in where it's not wanted :) -- 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] RC4
Built and tested cgi version ok on NT4 SP6 IIS4 - ran all my stuff which is mainly mysql + general language stuff, + phpmyadmin +phorum. Built and done a rudimentary test (some of my code + phpMyAdmin) on Suse 6.4 Linux, again with no problems found. 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] Unix timestamp maximum
Ideally it should not depend an operating system structure. Agreed (but quite a lot of work I think). I propose #define PHP_DATE_SIZE _int64 Not agreed, unless you move the start date backwards a few thousand years :) 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] PHP 4.0 Bug #10184 Updated: Define and empty multi line string fault
ID: 10184
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Strings related
Description: Define and empty multi line string fault
Previous Comments:
---
[2001-04-05 10:16:52] [EMAIL PROTECTED]
CODE USED-
$var = EOF
EOF;
define("CONSTANT", $var) ;
ERROR PRODUCED -
Warning: Constants may only evaluate to scalar values in
/home/sites/site5/cnf/lib2.cnf on line 26
The empty multi-line string does not evaluate to the same thing as:
$var = "";
Bug? Fault? User just being thick?
---
Full Bug description available at: http://bugs.php.net/?id=10184
--
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] Suggestion for bug system
Jani seems to have to waste several minutes each month clearing bugs from the database which are actually comments or fixes to do with the php web site. I'm sure that these several minutes put to better use would equate to another 10 bugs cleared:) Is it possible to add an extra category of 'php website' to the bug tracking system which causes the report to be just emailed the webmaster rather than entered into the system? 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
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]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt
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] RC7 is out
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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: 4.0.5: Merge Request
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]
[PHP-DEV] Re: [PHP-QA] RC8
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]
Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
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 N1) 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] Re: [PHP-DEV] Release process
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] Bug #10684 Updated: Installation Problem
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] Bug #10739 Updated: Zlib compile fails
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 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
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] Re: [PHP-QA] Modifications to Windows Readme file
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]
[PHP-DEV] Re: [PHP-QA] RE: [PHP-DEV] Re: [PHP-QA] Modifications to Windows Readme file
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]
[PHP-DEV] Re: [PHP-QA] RE: [PHP-DEV] Re: [PHP-QA] Modifications to Windows Readme file
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
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]
Re: [PHP-DEV] Is this still true?
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
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]
[PHP-DEV] Re: [PHP-QA] 4.0.6RC4 out.
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 br bWarning/b: Undefined variable: ext_found in brun-tests.php/b on line b307/bbr Running tests in /home/phil/php-4.0.6RC4/ext/crack/tests [all 1 test(s) skipped] br bWarning/b: Undefined variable: ext_found in brun-tests.php/b on line b307/bbr Running tests in /home/phil/php-4.0.6RC4/ext/ctype/tests [all 2 test(s) skipped] br bWarning/b: Undefined variable: ext_found in brun-tests.php/b on line b307/bbr Running tests in /home/phil/php-4.0.6RC4/ext/cybermut/tests === [all 1 test(s) skipped] br bWarning/b: Undefined variable: ext_found in brun-tests.php/b on line b307/bbr Running tests in /home/phil/php-4.0.6RC4/ext/db/tests = [all 6 test(s) skipped] br bWarning/b: Undefined variable: ext_found in brun-tests.php/b on line b307/bbr Running tests in /home/phil/php-4.0.6RC4/ext/gmp/tests == [all 2 test(s) skipped] br bWarning/b: Undefined variable: ext_found in brun-tests.php/b on line b307/bbr Running tests in /home/phil/php-4.0.6RC4/ext/iconv/tests [all 1 test(s) skipped] br bWarning/b: Undefined variable: ext_found in brun-tests.php/b on line b307/bbr Running tests in /home/phil/php-4.0.6RC4/ext/interbase/tests [all 6 test(s) skipped] br bWarning/b: Undefined variable: ext_found in brun-tests.php/b on line b307/bbr Running tests in /home/phil/php-4.0.6RC4/ext/mcrypt/tests = [all 1 test(s) skipped] br bWarning/b: Undefined variable: ext_found in brun-tests.php/b on line b307/bbr 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 br bWarning/b: Undefined variable: ext_found in brun-tests.php/b on line b307/bbr Running tests in /home/phil/php-4.0.6RC4/ext/skeleton/tests === [all 1 test(s) skipped] br bWarning/b: Undefined variable: ext_found in brun-tests.php/b on line b307/bbr Running tests in /home/phil/php-4.0.6RC4/ext/standard/tests/file File type functions ... passed br bWarning/b: Undefined variable: ext_found in brun-tests.php/b on line b307/bbr Running tests in /home/phil/php-4.0.6RC4/ext/standard/tests/math Simple math tests... passed br bWarning/b: Undefined variable: ext_found in brun-tests.php/b on line b307/bbr 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 br bWarning/b: Undefined variable: ext_found in brun-tests.php/b on line b307/bbr 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
Re: [PHP-DEV] 4.0.6
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-devphp-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.6 Packaged!
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]
[PHP-DEV] Re: FW: [PHP-QA] 4.0.6 Packaged!
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] 4.0.6
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!
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] Sablotron leaks
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]
[PHP-DEV] Tidying up the language
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]
[PHP-DEV] php 4.1 or php 5.0
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]
Re: [PHP-DEV] php 4.1 or php 5.0
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 guess 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]
Re: [PHP-DEV] Bug #11997: PHP Won't work on XP 2
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 insert FAQ URL. 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] Security Issues
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] Security Issues
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
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
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:
--
?php
if ($pass === hello) //= corrected to ===
$auth = 1;
...
if ($auth == 1)
echo some important information;
?
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.
--
?php
if (!($fd = fopen($filename, r))
echo(Could not open file: $filenameBR\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.
--
?php
include($libdir . /languages.php);
?
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.
--
?php
if (file_exists($theme)) // Checks the file exists on the local system (no
remote files)
include($theme);
?
This seems to be the same as the fopen($filename... example above.
--
In libdir/loadlanguage.php:
?php
...
include($langDir/$userLang);
?
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:
?php
...
include($langDir/_GET['userLang']);
?
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]
[PHP-DEV] thread safety
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
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]
Re: [PHP-DEV] Security Issues
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] Security Issues (isset stuff)
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 - a bit of my experience
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)
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 (isset stuff)
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] Portability concerns
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] Portability concerns
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
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]
[PHP-DEV] Re: [PHP-QA] 4.0.7RC1 rolled
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] 4.0.7RC1 rolled
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
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]
[PHP-DEV] Re: [PHP-QA] 4.0.7RC1 rolled
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] Re: [PHP-QA] 4.0.7RC1 rolled
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] RC2
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: [Zend Engine 2] Right/Left Shift Zero Fill operator
+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] RC3
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] RC3
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
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] Re: [PHP-QA] Re: RC3
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]
[PHP-DEV] Re: [PHP-QA] 4.1.0RC2
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] 4.1.0 Final RC
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] Re: [PHP-DEV] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status
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] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status
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]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status
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: Win32 Build for 4.1.0
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: Win32 Build for 4.1.0
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
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
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]
[PHP-DEV] Re: [PHP-QA] 4.1.0RC4
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]
[PHP-DEV] Re: [PHP-QA] 4.1.0RC5
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.0RC5
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]
Re: [PHP-DEV] Re: phpweb / downloads.php
On Wednesday 12 December 2001 7:23 pm, Gabor Hojtsy wrote: + li?php download_link(php-4.1.0-Win32.zip, PHP 4.1.0 zip package); ? - 12 + li?php download_link(php410-installer.exe, PHP 4.1.0 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]
Re: [PHP-DEV] Proposed patch for /php4/win32/install.txt
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] Proposed updates and extensions to the MySQL extension
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 updates and extensions to the MySQL extension
On Thursday 03 January 2002 2:18 pm, Markus Fischer wrote: On Thu, Jan 03, 2002 at 02:06:23PM +, 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
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]
[PHP-DEV] Bug #15281: OleMainThreadWndName: php.exe application error
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 -- head titleUntitled Document/title meta http-equiv=Content-Type content=text/html; charset=iso-8859-1 /head table tdbDname/b/td /tr ?php $connectionstring = odbc_pconnect(ODBCMSORACLE, scott, tiger); //$Query = SELECT dname FROM dept; //$queryexe = odbc_do($connectionstring, $Query); //odbc_fetch_row($queryexe); //$fname = odbc_result($queryexe, 1); //print (trtd$fname/td/tr); odbc_close($connectionstring); ? /table /body /html End Script -- -- Edit bug report at: http://bugs.php.net/?id=15281edit=1 -- 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] Bug #15293: Incorrect brackets in strlen crashes server
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=15293edit=1 -- 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] Bug #15293 Updated: Incorrect brackets in strlen crashes server
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=15293edit=1 -- 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] PHP Test results
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
Re: [PHP-DEV] PHP's vision
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] __CLASS__ and debug_backtrace()
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?
?
class base
{
function print_something()
{
echo __CLASS__.\n;
print_r(debug_backtrace());
}
}
class child extends base {}
child::print_something();
$c = new child();
$c-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
