Bug #60333 [Opn]: fetch_field() length multiplied by 3 in mysqlnd
Edit report at https://bugs.php.net/bug.php?id=60333edit=1
ID: 60333
User updated by:danielc at analysisandsolutions dot com
Reported by:danielc at analysisandsolutions dot com
Summary:fetch_field() length multiplied by 3 in mysqlnd
Status: Open
Type: Bug
Package:MySQLi related
Operating System: linux
PHP Version:5.4SVN-2011-11-19 (SVN)
Block user comment: N
Private report: N
New Comment:
Can this please be fixed before PHP 5.4 goes out the door?
Previous Comments:
[2011-11-21 18:04:38] danielc at analysisandsolutions dot com
That may be the case, but having UTF-8 fields is legit and the answers from
libmysql and mysqlnd should be the same.
[2011-11-21 17:59:23] william dot bailey at cowboysfromhell dot co dot uk
I think this might be down to what encoding the connection is using.
The length in bytes of a mysql utf8 CHAR(2) field is 6.
If you issue a $db-query('SET NAMES latin1'); before the CREATE TABLE then you
should get the results you are expecting.
[2011-11-19 02:38:53] danielc at analysisandsolutions dot com
Description:
Running PHP 5.4 compiled from svn earlier today. The length values from
fetch_field() are multiplied by 3 when building mysqli against mysqlnd. The
values are correct when building against libmysql.
Test script:
---
$db = new mysqli(null, $_ENV['MYSQL_TEST_USER'],
$_ENV['MYSQL_TEST_PASSWD'], $_ENV['MYSQL_TEST_DB'],
null, $_ENV['MYSQL_TEST_SOCKET']);
$result = $db-query(CREATE TEMPORARY TABLE phptest_fk (
txt TEXT NULL,
chr2 CHAR(2) default 'df' NOT NULL,
chr10 CHAR(10) default 'df' NOT NULL));
if (!$result) {
echo OOPS: $db-error\n;
exit(1);
}
$result = $db-query(INSERT INTO phptest_fk VALUES ('One', 'c1'));
$result = $db-query(SELECT * FROM phptest_fk);
$info = $result-fetch_field();
echo $info-name $info-length\n;
$info = $result-fetch_field();
echo $info-name $info-length\n;
$info = $result-fetch_field();
echo $info-name $info-length\n;
Expected result:
txt 65535
chr2 2
chr10 10
Actual result:
--
txt 196605
chr2 6
chr10 30
--
Edit this bug report at https://bugs.php.net/bug.php?id=60333edit=1
[PHP-BUG] Bug #60734 [NEW]: POST, SKIPIF and CLEAN fail if phpt path has spaces
From: Operating system: PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:POST, SKIPIF and CLEAN fail if phpt path has spaces Description: The POST, SKIPIF and CLEAN sections for phpt fail to execute if the path to the test file has spaces in it. Will attach a patch for run-tests.php. -- Edit bug report at https://bugs.php.net/bug.php?id=60734edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60734r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60734r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60734r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60734r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60734r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60734r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60734r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60734r=needscript Try newer version: https://bugs.php.net/fix.php?id=60734r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60734r=support Expected behavior: https://bugs.php.net/fix.php?id=60734r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60734r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60734r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60734r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60734r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60734r=dst IIS Stability: https://bugs.php.net/fix.php?id=60734r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60734r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60734r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60734r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60734r=mysqlcfg
[PHP-BUG] Bug #60362 [NEW]: non-existent sub-sub keys should not have values
From:
Operating system: linux
PHP version: 5.4SVN-2011-11-23 (SVN)
Package: Arrays related
Bug Type: Bug
Bug description:non-existent sub-sub keys should not have values
Description:
In an array, a sub-sub-key of an existing key is now returning a letter of
the value indexed by the main key. This is a regression in 5.4. PHP 5.3
still operates as expected. I suspect this is related to the array
dereferencing changes.
Test script:
---
$arr = array('exists' = 'foo');
if (isset($arr['exists']['non_existent'])) {
echo expected: sub-key 'non_existent' is set: ;
var_dump($arr['exists']['non_existent']);
} else {
echo BEHAVIOR CHANGED: sub-key 'non_existent' is not set.\n;
}
if (isset($arr['exists'][1])) {
echo expected: sub-key 1 is set: ;
var_dump($arr['exists'][1]);
} else {
echo BEHAVIOR CHANGED: sub-key 1 is not set.\n;
}
echo ---\n;
if (isset($arr['exists']['non_existent']['sub_sub'])) {
echo BEHAVIOR CHANGED: sub-key 'sub_sub' is set: ;
var_dump($arr['exists']['non_existent']['sub_sub']);
} else {
echo good: sub-sub-key 'sub_sub' is not set.\n;
}
if (isset($arr['exists'][1][0])) {
echo BEHAVIOR CHANGED: sub-sub-key 0 is set: ;
var_dump($arr['exists'][1][0]);
} else {
echo good: sub-sub-key 0 is not set.\n;
}
echo ---\n;
if (empty($arr['exists']['non_existent'])) {
echo BEHAVIOR CHANGED: sub-key 'non_existent' is empty.\n;
} else {
echo expected: sub-key 'non_existent' is not empty: ;
var_dump($arr['exists']['non_existent']);
}
if (empty($arr['exists'][1])) {
echo BEHAVIOR CHANGED: sub-key 1 is empty.\n;
} else {
echo expected: sub-key 1 is NOT empty: ;
var_dump($arr['exists'][1]);
}
echo ---\n;
if (empty($arr['exists']['non_existent']['sub_sub'])) {
echo good: sub-sub-key 'sub_sub' is empty.\n;
} else {
echo BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: ;
var_dump($arr['exists']['non_existent']['sub_sub']);
}
if (empty($arr['exists'][1][0])) {
echo good: sub-sub-key 0 is empty.\n;
} else {
echo BEHAVIOR CHANGED: sub-sub-key 0 is not empty: ;
var_dump($arr['exists'][1][0]);
}
Expected result:
expected: sub-key 'non_existent' is set: string(1) f
expected: sub-key 1 is set: string(1) o
---
good: sub-sub-key 'sub_sub' is not set.
good: sub-sub-key 0 is not set.
---
expected: sub-key 'non_existent' is not empty: string(1) f
expected: sub-key 1 is NOT empty: string(1) o
---
good: sub-sub-key 'sub_sub' is empty.
good: sub-sub-key 0 is empty.
Actual result:
--
expected: sub-key 'non_existent' is set: string(1) f
expected: sub-key 1 is set: string(1) o
---
BEHAVIOR CHANGED: sub-key 'sub_sub' is set: string(1) f
BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) o
---
expected: sub-key 'non_existent' is not empty: string(1) f
expected: sub-key 1 is NOT empty: string(1) o
---
BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: string(1) f
BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) o
--
Edit bug report at https://bugs.php.net/bug.php?id=60362edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60362r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60362r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60362r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60362r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60362r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60362r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60362r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60362r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60362r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60362r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60362r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60362r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60362r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60362r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60362r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60362r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60362r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60362r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60362r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60362r=nozend
MySQL
Bug #60333 [Opn]: fetch_field() length multiplied by 3 in mysqlnd
Edit report at https://bugs.php.net/bug.php?id=60333edit=1
ID: 60333
User updated by:danielc at analysisandsolutions dot com
Reported by:danielc at analysisandsolutions dot com
Summary:fetch_field() length multiplied by 3 in mysqlnd
Status: Open
Type: Bug
Package:MySQLi related
Operating System: linux
PHP Version:5.4SVN-2011-11-19 (SVN)
Block user comment: N
Private report: N
New Comment:
That may be the case, but having UTF-8 fields is legit and the answers from
libmysql and mysqlnd should be the same.
Previous Comments:
[2011-11-21 17:59:23] william dot bailey at cowboysfromhell dot co dot uk
I think this might be down to what encoding the connection is using.
The length in bytes of a mysql utf8 CHAR(2) field is 6.
If you issue a $db-query('SET NAMES latin1'); before the CREATE TABLE then you
should get the results you are expecting.
[2011-11-19 02:38:53] danielc at analysisandsolutions dot com
Description:
Running PHP 5.4 compiled from svn earlier today. The length values from
fetch_field() are multiplied by 3 when building mysqli against mysqlnd. The
values are correct when building against libmysql.
Test script:
---
$db = new mysqli(null, $_ENV['MYSQL_TEST_USER'],
$_ENV['MYSQL_TEST_PASSWD'], $_ENV['MYSQL_TEST_DB'],
null, $_ENV['MYSQL_TEST_SOCKET']);
$result = $db-query(CREATE TEMPORARY TABLE phptest_fk (
txt TEXT NULL,
chr2 CHAR(2) default 'df' NOT NULL,
chr10 CHAR(10) default 'df' NOT NULL));
if (!$result) {
echo OOPS: $db-error\n;
exit(1);
}
$result = $db-query(INSERT INTO phptest_fk VALUES ('One', 'c1'));
$result = $db-query(SELECT * FROM phptest_fk);
$info = $result-fetch_field();
echo $info-name $info-length\n;
$info = $result-fetch_field();
echo $info-name $info-length\n;
$info = $result-fetch_field();
echo $info-name $info-length\n;
Expected result:
txt 65535
chr2 2
chr10 10
Actual result:
--
txt 196605
chr2 6
chr10 30
--
Edit this bug report at https://bugs.php.net/bug.php?id=60333edit=1
Bug #31455 [Com]: multiple session_start() creates multiple session cookies in HTTP-Response
Edit report at https://bugs.php.net/bug.php?id=31455edit=1
ID: 31455
Comment by: danielc at analysisandsolutions dot com
Reported by:rene dot bangemann at web dot de
Summary:multiple session_start() creates multiple session
cookies in HTTP-Response
Status: Wont fix
Type: Bug
Package:Session related
Operating System: Win32
PHP Version:4CVS, 5CVS
Assigned To:tony2001
Block user comment: N
Private report: N
New Comment:
See also: https://bugs.php.net/bug.php?id=31455
Previous Comments:
[2010-10-15 23:26:30] WarrenGaebel at FriendlyNeighbourGuide dot ca
I am experiencing a similar, but not identical problem.
I reload my page multiple times, using session_start() every time it loads.
JavaScript sets cookies that I use in php. When using Internet Explorer,
$_ENV[HTTP_COOKIE] contains multiple entries for each cookie. This does not
happen with Firefox.
As near as I can figure so far, when executing code at a domain named x.y.z,
Internet Explorer sends the cookies for x.y.z followed by the cookies for y.z.
Php then puts both sets of cookies into $_ENV[HTTP_COOKIE].
Perhaps this may be considered a PHP bug, perhaps not. IMHO, this is an
Internet Explorer bug. I post it here in the hope that it may help you resolve
your problem.
... Warren Gaebel, B.A., B.C.S.
[2005-02-14 00:18:30] rene dot bangemann at web dot de
Ok, you are right that someone could start several sessions within one request.
But thats not my use case:
I'm using a PHP script to perform some actions which can take up to some hours.
E.G. for displaying progress information about the running process a second php
script needs to access the session vars. This forces to close the session file
via session_write_close() in the first script. After this function call, the
second PHP script can do a session_start() and access the current values of the
session vars.
After finishing the second request the session file will be closed again.
If the first script has to store new values of session related vars in the
session file, it uses a combination of session_start() and
session_write_close() to update the content within the session file.
Unfortunatly in my case this can happen very often (because of the long
execution time).
Under normal circumstances I could live with this feature :-). But I'm afraid
that in combination with HTML frames this behaviour of PHP can force deadlocks
in different browsers like Internet Explorer or Mozilla. Unfortunately I can't
present a 100% working example for reproducable deadlocks.
I would suggest to create a flag containing true or false, if the Cookie for
the current session id already was sent or not.
If the cookie wasn't already sent, or the used session id changes, of course
another Cookie has to be sent.
[2005-02-13 18:03:51] tony2...@php.net
Okay, no more dirty hacks =)
Marking it as won't fix and considering as a feature.
[2005-02-13 09:44:30] sni...@php.net
Then how would you handle this (very unlikely :) code:
?php
session_name('foo1');
session_id('foobar1');
session_start();
session_write_close();
session_name('foo2');
session_id('foobar2');
session_start();
session_write_close();
session_name('foo3');
session_id('foobar3');
session_start();
session_write_close();
?
Yes, someone MIGHT rely on that kind of code too.
And as it IS possible to start as many _different_ sessions in single
request, why should we not allow it?
(this is actually for Tony, FYI when he figures out how to fix this bug :)
[2005-01-09 15:49:13] rene dot bangemann at web dot de
Description:
I'm using a combination of session_start() and session_write_close() to access
and update session variables.
In some scripts this function calls will be executed up to 50 times.
For each call of session_start() a HTTP-Header with the PHP session id will be
created in the same HTTP response.
I would expect, that in the HTTP response will be only one HTTP-Header with the
session id.
Reproduce code:
---
?php
session_start();
session_write_close();
session_start();
session_write_close();
session_start();
session_write_close();
?
Expected result:
HTTP-Header Set-Cookie with PHP session id created only once in HTTP response
Actual result:
--
The code above will create a HTTP response with three identical HTTP Set-Cookie
headers
--
Edit this bug report at https
Bug #31455 [Com]: multiple session_start() creates multiple session cookies in HTTP-Response
Edit report at https://bugs.php.net/bug.php?id=31455edit=1
ID: 31455
Comment by: danielc at analysisandsolutions dot com
Reported by:rene dot bangemann at web dot de
Summary:multiple session_start() creates multiple session
cookies in HTTP-Response
Status: Wont fix
Type: Bug
Package:Session related
Operating System: Win32
PHP Version:4CVS, 5CVS
Assigned To:tony2001
Block user comment: N
Private report: N
New Comment:
I mean to say, see also: https://bugs.php.net/bug.php?id=38104
Previous Comments:
[2011-11-20 05:21:02] danielc at analysisandsolutions dot com
See also: https://bugs.php.net/bug.php?id=31455
[2010-10-15 23:26:30] WarrenGaebel at FriendlyNeighbourGuide dot ca
I am experiencing a similar, but not identical problem.
I reload my page multiple times, using session_start() every time it loads.
JavaScript sets cookies that I use in php. When using Internet Explorer,
$_ENV[HTTP_COOKIE] contains multiple entries for each cookie. This does not
happen with Firefox.
As near as I can figure so far, when executing code at a domain named x.y.z,
Internet Explorer sends the cookies for x.y.z followed by the cookies for y.z.
Php then puts both sets of cookies into $_ENV[HTTP_COOKIE].
Perhaps this may be considered a PHP bug, perhaps not. IMHO, this is an
Internet Explorer bug. I post it here in the hope that it may help you resolve
your problem.
... Warren Gaebel, B.A., B.C.S.
[2005-02-14 00:18:30] rene dot bangemann at web dot de
Ok, you are right that someone could start several sessions within one request.
But thats not my use case:
I'm using a PHP script to perform some actions which can take up to some hours.
E.G. for displaying progress information about the running process a second php
script needs to access the session vars. This forces to close the session file
via session_write_close() in the first script. After this function call, the
second PHP script can do a session_start() and access the current values of the
session vars.
After finishing the second request the session file will be closed again.
If the first script has to store new values of session related vars in the
session file, it uses a combination of session_start() and
session_write_close() to update the content within the session file.
Unfortunatly in my case this can happen very often (because of the long
execution time).
Under normal circumstances I could live with this feature :-). But I'm afraid
that in combination with HTML frames this behaviour of PHP can force deadlocks
in different browsers like Internet Explorer or Mozilla. Unfortunately I can't
present a 100% working example for reproducable deadlocks.
I would suggest to create a flag containing true or false, if the Cookie for
the current session id already was sent or not.
If the cookie wasn't already sent, or the used session id changes, of course
another Cookie has to be sent.
[2005-02-13 18:03:51] tony2...@php.net
Okay, no more dirty hacks =)
Marking it as won't fix and considering as a feature.
[2005-02-13 09:44:30] sni...@php.net
Then how would you handle this (very unlikely :) code:
?php
session_name('foo1');
session_id('foobar1');
session_start();
session_write_close();
session_name('foo2');
session_id('foobar2');
session_start();
session_write_close();
session_name('foo3');
session_id('foobar3');
session_start();
session_write_close();
?
Yes, someone MIGHT rely on that kind of code too.
And as it IS possible to start as many _different_ sessions in single
request, why should we not allow it?
(this is actually for Tony, FYI when he figures out how to fix this bug :)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=31455
--
Edit this bug report at https://bugs.php.net/bug.php?id=31455edit=1
Bug #38104 [Com]: session_start()/session_write_close() creates multiple session cookies headers
Edit report at https://bugs.php.net/bug.php?id=38104edit=1
ID: 38104
Comment by: danielc at analysisandsolutions dot com
Reported by:m dot v dot veluw dot smscity at gmail dot com
Summary:session_start()/session_write_close() creates
multiple session cookies headers
Status: Bogus
Type: Bug
Package:Session related
Operating System: any
PHP Version:5.1.4
Block user comment: N
Private report: N
New Comment:
See also https://bugs.php.net/bug.php?id=31455
Previous Comments:
[2011-11-09 18:34:52] rfunk at funknet dot net
I just ran into this bug in PHP 5.3.5 when working with a script that does lots
of
session_start()/session_write_close() in a long-running task, so that separate
requests can still access the
session during that long task. (Specifically those separate requests are
checking the progress of the long
task.)
The resulting absurdly redundant Set-Cookie header caused Firefox 7 to lock up
for a few seconds, and caused IE8
to give its infamously useless Internet Explorer cannot display the webpage
page. So this bug is not Bogus s
it claims.
I do have a workaround, however. I'm already doing an ob_start() at the top of
the script, and now before the
ending ob_end_flush() I replace the Set-Cookie header with a new one:
if (SID) header('Set-Cookie: '.SID.'; path=/', true);
After adding this, I no longer have the above problems in Firefox and IE.
[2011-02-04 17:00:58] vdklah at hotmail dot com
I can not tell how much I disagree on this. Calling session_start() followed by
session_write_close() is a very valid way to avoid blocking multiple processes.
(See also here http://konrness.com/php5/how-to-prevent-blocking-php-requests/.)
This problem is huge since we are facing fatal crashing clients due to zillions
of duplicate PHPSESSID entries in one cookie. Our server is big and complicated
and so we are not willing to change anything in this area while all is already
taken in production. Totally stuck on this and I'm not happy. This is a very
obvious PHP bug that can be proven in 4 lines of code without any client
intervention.
[2006-07-14 20:46:11] il...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Session is created every time you call session_start(). If you
want to avoid multiple cookie, write better code. Multiple
session_start() especially for the same names in the same
script seems like a really bad idea.
[2006-07-14 10:23:58] m dot v dot veluw dot smscity at gmail dot com
Description:
When using session_start() and session_write_close() with the same session
id/name will add multiple session cookies with the exact same contents
everytime session_start is used.
This is useless overhead if it is the same.
Reproduce code:
---
session_name('uniqueName1');
session_start();
$_SESSION['Foo1'] = 'Bar1';
session_write_close();
session_name('uniqueName2');
session_start();
$_SESSION['Foo2'] = 'Bar2';
session_write_close();
session_name('uniqueName1');
session_start();
$sessionValue = $_SESSION['Foo1'];
print $sessionValue;
session_write_close();
session_name('uniqueName2');
session_start();
$sessionValue = $_SESSION['Foo2'];
print $sessionValue;
session_write_close();
Expected result:
just 1 session cookie header for uniqueName1.
just 1 session cookie header for uniqueName2.
Actual result:
--
2 session cookie headers for uniqueName1, where both are exactly the same
2 session cookie headers for uniqueName2, where both are exactly the same
--
Edit this bug report at https://bugs.php.net/bug.php?id=38104edit=1
[PHP-BUG] Bug #60333 [NEW]: fetch_field() length multiplied by 3 in mysqlnd
From:
Operating system: linux
PHP version: 5.4SVN-2011-11-19 (SVN)
Package: MySQLi related
Bug Type: Bug
Bug description:fetch_field() length multiplied by 3 in mysqlnd
Description:
Running PHP 5.4 compiled from svn earlier today. The length values from
fetch_field() are multiplied by 3 when building mysqli against mysqlnd.
The values are correct when building against libmysql.
Test script:
---
$db = new mysqli(null, $_ENV['MYSQL_TEST_USER'],
$_ENV['MYSQL_TEST_PASSWD'], $_ENV['MYSQL_TEST_DB'],
null, $_ENV['MYSQL_TEST_SOCKET']);
$result = $db-query(CREATE TEMPORARY TABLE phptest_fk (
txt TEXT NULL,
chr2 CHAR(2) default 'df' NOT NULL,
chr10 CHAR(10) default 'df' NOT NULL));
if (!$result) {
echo OOPS: $db-error\n;
exit(1);
}
$result = $db-query(INSERT INTO phptest_fk VALUES ('One', 'c1'));
$result = $db-query(SELECT * FROM phptest_fk);
$info = $result-fetch_field();
echo $info-name $info-length\n;
$info = $result-fetch_field();
echo $info-name $info-length\n;
$info = $result-fetch_field();
echo $info-name $info-length\n;
Expected result:
txt 65535
chr2 2
chr10 10
Actual result:
--
txt 196605
chr2 6
chr10 30
--
Edit bug report at https://bugs.php.net/bug.php?id=60333edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60333r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60333r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60333r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60333r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60333r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60333r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60333r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60333r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60333r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60333r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60333r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60333r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60333r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60333r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60333r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60333r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60333r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60333r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60333r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60333r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60333r=mysqlcfg
[PHP-BUG] Bug #55253 [NEW]: DateTime::add() and sub() result -1 hour on objects with time zone type 2
From:
Operating system: Ubuntu 10.04
PHP version: 5.4SVN-2011-07-20 (SVN)
Package: Date/time related
Bug Type: Bug
Bug description:DateTime::add() and sub() result -1 hour on objects with time
zone type 2
Description:
Calling add() or sub() on DateTime objects using a type 2 time zone results
in the answer being behind by one hour.
Test script has been added to SVN.
Test script:
---
date_default_timezone_set('America/New_York');
$interval = new DateInterval('PT2H1M');
$date3 = new DateTime('2010-10-04 02:18:48');
$date2 = new DateTime('2010-10-04 02:18:48 EDT');
echo 'Zone Type 3: ' . $date3-format('Y-m-d H:i:s T') . \n;
echo 'Zone Type 2: ' . $date2-format('Y-m-d H:i:s T') . \n;
echo $interval-format('Add %h hours %i minutes') . \n;
$date3-add($interval);
$date2-add($interval);
echo 'Zone Type 3: ' . $date3-format('Y-m-d H:i:s T') . \n;
echo 'Zone Type 2: ' . $date2-format('Y-m-d H:i:s T') . \n;
// Try subtracting from expected result.
$date3 = new DateTime('2010-10-04 04:19:48');
$date2 = new DateTime('2010-10-04 04:19:48 EDT');
echo $interval-format('Subtract %h hours %i minutes from expected') .
\n;
$date3-sub($interval);
$date2-sub($interval);
echo 'Zone Type 3: ' . $date3-format('Y-m-d H:i:s T') . \n;
echo 'Zone Type 2: ' . $date2-format('Y-m-d H:i:s T') . \n;
Expected result:
Zone Type 3: 2010-10-04 02:18:48 EDT
Zone Type 2: 2010-10-04 02:18:48 EDT
Add 2 hours 1 minutes
Zone Type 3: 2010-10-04 04:19:48 EDT
Zone Type 2: 2010-10-04 04:19:48 EDT
Subtract 2 hours 1 minutes from expected
Zone Type 3: 2010-10-04 02:18:48 EDT
Zone Type 2: 2010-10-04 02:18:48 EDT
Actual result:
--
Zone Type 3: 2010-10-04 02:18:48 EDT
Zone Type 2: 2010-10-04 02:18:48 EDT
Add 2 hours 1 minutes
Zone Type 3: 2010-10-04 04:19:48 EDT
Zone Type 2: 2010-10-04 03:19:48 EDT
Subtract 2 hours 1 minutes from expected
Zone Type 3: 2010-10-04 02:18:48 EDT
Zone Type 2: 2010-10-04 01:18:48 EDT
--
Edit bug report at https://bugs.php.net/bug.php?id=55253edit=1
--
Try a snapshot (PHP 5.2):
https://bugs.php.net/fix.php?id=55253r=trysnapshot52
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55253r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55253r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55253r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55253r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55253r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55253r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55253r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55253r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55253r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55253r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55253r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55253r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55253r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55253r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55253r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55253r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55253r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55253r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55253r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55253r=mysqlcfg
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55253r=trysnapshot54
Bug #53634 [Asn]: unknown property when writing to DateInterval::$days
Edit report at http://bugs.php.net/bug.php?id=53634edit=1
ID: 53634
User updated by:danielc at analysisandsolutions dot com
Reported by:danielc at analysisandsolutions dot com
Summary:unknown property when writing to DateInterval::$days
Status: Assigned
Type: Bug
Package:Date/time related
Operating System: linux
PHP Version:5.3SVN-2010-12-30 (SVN)
Assigned To:stas
Block user comment: N
Private report: N
New Comment:
Why should days be read only? All other properties are writable. Days
needs to be writable too. Writing to various properties is necessary
when overloading the date classes (to compensate for bugs, etc).
Previous Comments:
[2011-01-30 11:57:20] s...@php.net
Hmm... Actually you're not supposed to be writing to days property, it
should be read only. I'll fix it.
[2011-01-24 18:39:45] danielc at analysisandsolutions dot com
While the recent commit removes the fatal error, the property can not be
written to. Here is the output of the initial test script (above) as of
svn revision 307713:
S: 8
DAYS: -9
DAYS: -9
[2011-01-24 03:49:50] s...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2010-12-30 22:15:05] danielc at analysisandsolutions dot com
Description:
One can not set the DateInterval::$days property. It is readable. All
other properties of DateInterval shown in var_dump() are writeable.
While similar to Bug #52738, this involves an actual property of the
DateInterval class.
Test script:
---
$i = new DateInterval('P1D');
$i-s = 8;
echo S: $i-s\n;
echo DAYS: $i-days\n;
$i-days = 6;
echo DAYS: $i-days\n;
Expected result:
S: 8
DAYS: -9
DAYS: 6
Actual result:
--
S: 8
DAYS: -9
PHP Fatal error: main(): Unknown property (days) in
/home/danielc/test.php on line 7
--
Edit this bug report at http://bugs.php.net/bug.php?id=53634edit=1
Bug #53634 [Csd-Asn]: unknown property when writing to DateInterval::$days
Edit report at http://bugs.php.net/bug.php?id=53634edit=1
ID: 53634
User updated by:danielc at analysisandsolutions dot com
Reported by:danielc at analysisandsolutions dot com
Summary:unknown property when writing to DateInterval::$days
-Status: Closed
+Status: Assigned
Type: Bug
Package:Date/time related
Operating System: linux
PHP Version:5.3SVN-2010-12-30 (SVN)
Assigned To:stas
Block user comment: N
Private report: N
New Comment:
While the recent commit removes the fatal error, the property can not be
written to. Here is the output of the initial test script (above) as of
svn revision 307713:
S: 8
DAYS: -9
DAYS: -9
Previous Comments:
[2011-01-24 03:49:50] s...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2010-12-30 22:15:05] danielc at analysisandsolutions dot com
Description:
One can not set the DateInterval::$days property. It is readable. All
other properties of DateInterval shown in var_dump() are writeable.
While similar to Bug #52738, this involves an actual property of the
DateInterval class.
Test script:
---
$i = new DateInterval('P1D');
$i-s = 8;
echo S: $i-s\n;
echo DAYS: $i-days\n;
$i-days = 6;
echo DAYS: $i-days\n;
Expected result:
S: 8
DAYS: -9
DAYS: 6
Actual result:
--
S: 8
DAYS: -9
PHP Fatal error: main(): Unknown property (days) in
/home/danielc/test.php on line 7
--
Edit this bug report at http://bugs.php.net/bug.php?id=53634edit=1
[PHP-BUG] Bug #53634 [NEW]: unknown property when writing to DateInterval::$days
From:
Operating system: linux
PHP version: 5.3SVN-2010-12-30 (SVN)
Package: Date/time related
Bug Type: Bug
Bug description:unknown property when writing to DateInterval::$days
Description:
One can not set the DateInterval::$days property. It is readable. All
other properties of DateInterval shown in var_dump() are writeable.
While similar to Bug #52738, this involves an actual property of the
DateInterval class.
Test script:
---
$i = new DateInterval('P1D');
$i-s = 8;
echo S: $i-s\n;
echo DAYS: $i-days\n;
$i-days = 6;
echo DAYS: $i-days\n;
Expected result:
S: 8
DAYS: -9
DAYS: 6
Actual result:
--
S: 8
DAYS: -9
PHP Fatal error: main(): Unknown property (days) in /home/danielc/test.php
on line 7
--
Edit bug report at http://bugs.php.net/bug.php?id=53634edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53634r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53634r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53634r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53634r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53634r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53634r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53634r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53634r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53634r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53634r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53634r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53634r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53634r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53634r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53634r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53634r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53634r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53634r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53634r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53634r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53634r=mysqlcfg
Bug #51051 [Com]: DateTime modify wrong result with DST change
Edit report at http://bugs.php.net/bug.php?id=51051edit=1
ID: 51051
Comment by: danielc at analysisandsolutions dot com
Reported by:mehdi dot rande at aliasource dot fr
Summary:DateTime modify wrong result with DST change
Status: Assigned
Type: Bug
Package:Date/time related
Operating System: Linux
PHP Version:5.3.1
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
DateTime::diff() is similarly afflicted with daylight/standard change
over issues. Naturally, diff/add/sub all need to be in sync so
intervals returned by diff can be passed to add/sub and produce the
original datetime.
Previous Comments:
[2010-12-25 02:27:22] dani...@php.net
I just attached a test script that covers issues in the spring and fall.
[2010-12-25 02:26:16] dani...@php.net
The following patch has been added/updated:
Patch Name: bug51051test.php.txt
Revision: 1293240376
URL:
http://bugs.php.net/patch-display.php?bug=51051patch=bug51051test.php.txtrevision=1293240376
[2010-08-24 14:34:22] glennpratt+php at gmail dot com
Correction for the Expected result above.
Expected Result
---
2011-03-13T03:00:00-05:00 America/Chicago
2011-03-13T01:58:00-06:00 America/Chicago
[2010-08-24 00:04:28] glennpratt at gmail dot com
Same issue here on PHP 5.3.2
?php
$date = new DateTime('2011-03-13T03:00:00',
timezone_open('America/Chicago'));
print($date-format('c e'));
$date-modify('-2 minutes');
print($date-format('c e'));
?
Actual Result
-
2011-03-13T03:00:00-05:00 America/Chicago
2011-03-13T03:58:00-05:00 America/Chicago
Expected Result
---
2011-03-13T03:00:00-05:00 America/Chicago
2011-03-13T01:58:00-05:00 America/Chicago
Comparison: Ruby time library
-
irb(main):015:0 date = Time.parse('2011-03-13T03:00:00 in CST')
= Sun Mar 13 03:00:00 -0500 2011
irb(main):016:0 date - 120
= Sun Mar 13 01:58:00 -0600 2011
[2010-02-15 10:56:45] mehdi dot rande at aliasource dot fr
Sorry the expected result is in fact the actual result, and the actual
result is the expected result.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=51051
--
Edit this bug report at http://bugs.php.net/bug.php?id=51051edit=1
[PHP-BUG] Bug #53463 [NEW]: sqlite3 columnName() segfaults on bad column_number
From:
Operating system: linux
PHP version: 5.3SVN-2010-12-03 (SVN)
Package: SQLite related
Bug Type: Bug
Bug description:sqlite3 columnName() segfaults on bad column_number
Description:
PHP's SQLite3Result::columnName() method produces a segmentation fault when
column_number exceeds the column count.
Inside ext/sqlite3/sqlite3.c, PHP utlizes RETVAL_STRING for the data coming
back from SQLite's sqlite3_column_name() function. But inside
ext/sqlite3/libsqlite/sqlite3.c, their sqlite3_column_name() function calls
columnName(), which returns 0 on error conditions.
PHP's C code needs to be adjusted to account for mixed type results from
sqlite3_column_name(). When making this fix, it seems PHP should return
FALSE if sqlite3_column_name() produces 0.
Test script:
---
$db = new SQLite3(':memory:');
$db-exec('CREATE TABLE test (whatever INTEGER)');
$db-exec('INSERT INTO test (whatever) VALUES (1)');
$result = $db-query('SELECT * FROM test');
while ($row = $result-fetchArray(SQLITE3_NUM)) {
var_dump($result-columnName(0)); // string(8) whatever
// Seems returning false will be most appropriate.
var_dump($result-columnName(3)); // Segmentation fault
}
$result-finalize();
$db-close();
echo Done\n;
Expected result:
string(8) whatever
bool(false)
Done
Actual result:
--
string(8) whatever
Segmentation fault
--
Edit bug report at http://bugs.php.net/bug.php?id=53463edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53463r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53463r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53463r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53463r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53463r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53463r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53463r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53463r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53463r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53463r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53463r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53463r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53463r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53463r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53463r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53463r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53463r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53463r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53463r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53463r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53463r=mysqlcfg
[PHP-BUG] Bug #53464 [NEW]: sqlite3 columnType() returns SQLITE3_NULL on bad column_number
From:
Operating system: linux
PHP version: 5.3SVN-2010-12-03 (SVN)
Package: SQLite related
Bug Type: Bug
Bug description:sqlite3 columnType() returns SQLITE3_NULL on bad column_number
Description:
The SQLite3Result::columnType() method returns SQLITE3_NULL (5) when
column_number exceeds the column count. It seems more appropriate for it
to return FALSE.
Test script:
---
$db = new SQLite3(':memory:');
$db-exec('CREATE TABLE test (whatever INTEGER)');
$db-exec('INSERT INTO test (whatever) VALUES (1)');
$result = $db-query('SELECT * FROM test');
while ($row = $result-fetchArray(SQLITE3_NUM)) {
var_dump($result-columnType(0)); // int(1) [SQLITE3_INTEGER]
// Seems returning false is more appropriate.
var_dump($result-columnType(3)); // int(5) [SQLITE3_NULL]
}
$result-finalize();
$db-close();
echo Done\n;
Expected result:
int(1)
bool(false)
Done
Actual result:
--
int(1)
int(5)
Done
--
Edit bug report at http://bugs.php.net/bug.php?id=53464edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53464r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53464r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53464r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53464r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53464r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53464r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53464r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53464r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53464r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53464r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53464r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53464r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53464r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53464r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53464r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53464r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53464r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53464r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53464r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53464r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53464r=mysqlcfg
[PHP-BUG] Req #53466 [NEW]: sqlite3 columnType() returns SQLITE3_NULL when not in fetch loop
From:
Operating system: linux
PHP version: 5.3SVN-2010-12-03 (SVN)
Package: SQLite related
Bug Type: Feature/Change Request
Bug description:sqlite3 columnType() returns SQLITE3_NULL when not in fetch loop
Description:
The SQLite3Result::columnType() method returns SQLITE3_NULL (5) if not
looping over results. This is done because the data type is unknown. But
this leads to confusion, because SQLITE3_NULL is a legitimate answer in
some cases when inside the loop. It would be clearer if PHP returned NULL
or FALSE instead.
Test script:
---
$db = new SQLite3(':memory:');
$db-exec('CREATE TABLE test (whatever INTEGER)');
$db-exec('INSERT INTO test (whatever) VALUES (1)');
$result = $db-query('SELECT * FROM test');
while ($row = $result-fetchArray(SQLITE3_NUM)) {
var_dump($result-columnType(0)); // int(1) [SQLITE3_INTEGER]
}
// Seems returning null or false is more appropriate.
var_dump($result-columnType(0)); // int(5) [SQLITE3_NULL]
$result-finalize();
$db-close();
echo Done\n;
Expected result:
int(1)
bool(false)
Done
Actual result:
--
int(1)
int(5)
Done
--
Edit bug report at http://bugs.php.net/bug.php?id=53466edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53466r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53466r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53466r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53466r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53466r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53466r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53466r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53466r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53466r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53466r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53466r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53466r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53466r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53466r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53466r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53466r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53466r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53466r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53466r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53466r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53466r=mysqlcfg
#50680 [NEW]: eight - eighth
From: danielc at analysisandsolutions dot com Operating system: PHP version: 5.3SVN-2010-01-06 (SVN) PHP Bug Type: Date/time related Bug description: eight - eighth Description: In ext/date/lib/parse_date.re, reltextnumber and timelib_reltext_lookup contain ordinal numbers, but when it comes to 8th, it mistakenly uses eight, rather than eighth. Guess it now needs to contain both to provide backwards compatibility. -- Edit bug report at http://bugs.php.net/?id=50680edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50680r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50680r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50680r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50680r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50680r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50680r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50680r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50680r=needscript Try newer version: http://bugs.php.net/fix.php?id=50680r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50680r=support Expected behavior: http://bugs.php.net/fix.php?id=50680r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50680r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50680r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50680r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50680r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50680r=dst IIS Stability: http://bugs.php.net/fix.php?id=50680r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50680r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50680r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50680r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50680r=mysqlcfg
#47629 [Opn]: mysqli connect timeout causes fatal error
ID: 47629 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Open Bug Type: MySQLi related Operating System: Windows XP SP3 PHP Version: 5.3CVS-2009-03-12 (snap) Assigned To: pajoye New Comment: I'll put together tests of the various functions and report back. Previous Comments: [2009-06-21 09:04:11] paj...@php.net 1) That's how PHP 5.2 does it. Not really relevant in this case. 2) That's how the other socket functions do it in 5.2 and 5.3. Then there is a bug here. 3) The timeout is from communication with another entity, not from the script itself. The max_execution_time has the highest priority and should always has it. If it is not the case in one function or another then there is a bug in this function. [2009-06-21 00:48:41] danielc at analysisandsolutions dot com Because: 1) That's how PHP 5.2 does it. 2) That's how the other socket functions do it in 5.2 and 5.3. 3) The timeout is from communication with another entity, not from the script itself. [2009-06-20 20:12:24] paj...@php.net but there is no bug here. Why do you want to let the socket timeout override the main timeout? [2009-06-20 17:34:32] dani...@php.net Yes, the execution timeout makes sense some ways. The problem is the behavior is inconsistent between 5.2 and 5.3 and between other connection functions. [2009-06-20 13:19:04] paj...@php.net With: max_execution_time: 2 default_socket_timeout: 6 It is the expected behavior to have a fatal error about the maximum execution time being exceeded. max_execution_time has the highest importance. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47629 -- Edit this bug report at http://bugs.php.net/?id=47629edit=1
#47629 [Fbk-Opn]: mysqli connect timeout causes fatal error
ID: 47629
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: Windows XP SP3
PHP Version: 5.3CVS-2009-03-12 (snap)
Assigned To: pajoye
New Comment:
Because:
1) That's how PHP 5.2 does it.
2) That's how the other socket functions do it in 5.2 and 5.3.
3) The timeout is from communication with another entity, not from the
script itself.
Previous Comments:
[2009-06-20 20:12:24] paj...@php.net
but there is no bug here. Why do you want to let the socket timeout
override the main timeout?
[2009-06-20 17:34:32] dani...@php.net
Yes, the execution timeout makes sense some ways. The problem is the
behavior is inconsistent between 5.2 and 5.3 and between other
connection functions.
[2009-06-20 13:19:04] paj...@php.net
With:
max_execution_time: 2
default_socket_timeout: 6
It is the expected behavior to have a fatal error about the maximum
execution time being exceeded. max_execution_time has the highest
importance.
[2009-03-12 04:41:21] danielc at analysisandsolutions dot com
Description:
A fatal error is generated if a MySQLi connection attempt times out AND
the default_socket_timeout ini setting is greater that the
max_execution_time ini setting. This is happening in PHP 5.3, Mar 11
2009 17:04:24, VC6 thread safe snapshot build.
This does not happen on timeouts when using socket_bind().
This does not happen in PHP 5.2.9-1.
Reproduce code:
---
// BOGUS MYSQL PORT NUMBER IS INTENTIONAL.
echo 'PHP ' . phpversion() . \n\n;
echo ONE ---\n;
ini_set('max_execution_time', 6);
ini_set('default_socket_timeout', 2);
echo 'max_execution_time: ' . ini_get('max_execution_time') . \n;
echo 'default_socket_timeout: ' . ini_get('default_socket_timeout') .
\n;
$mysqli = new mysqli('localhost', 'does', 'not', 'matter', 1);
if ($mysqli-connect_error) {
echo GOOD CATCH\n\n;
}
echo TWO ---\n;
ini_set('max_execution_time', 2);
ini_set('default_socket_timeout', 6);
echo 'max_execution_time: ' . ini_get('max_execution_time') . \n;
echo 'default_socket_timeout: ' . ini_get('default_socket_timeout') .
\n;
$mysqli = new mysqli('localhost', 'does', 'not', 'matter', 1);
if ($mysqli-connect_error) {
echo GOOD CATCH\n\n;
}
Expected result:
PHP 5.3.0beta2-dev
ONE ---
max_execution_time: 6
default_socket_timeout: 2
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
GOOD CATCH
TWO ---
max_execution_time: 2
default_socket_timeout: 6
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
GOOD CATCH
Actual result:
--
PHP 5.3.0beta2-dev
ONE ---
max_execution_time: 6
default_socket_timeout: 2
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
GOOD CATCH
TWO ---
max_execution_time: 2
default_socket_timeout: 6
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
Fatal error: Maximum execution time of 2 seconds exceeded in ...
--
Edit this bug report at http://bugs.php.net/?id=47629edit=1
#47627 [NEW]: No input file specified causing crash
From: danielc at analysisandsolutions dot com Operating system: Windows XP Pro SP3 PHP version: 5.3CVS-2009-03-11 (snap) PHP Bug Type: CGI related Bug description: No input file specified causing crash Description: In PHP 5.3, pointing my browser to a .php file that does not exist causes php-cgi to crash and Apache to return a 500 error. In PHP 5.2.6, doing so returns output saying No input file specified. During the crash, Windows displays the Please tell Microsoft about this problem dialog box. The title is CGI / FastCGI. The To see what data this error report contains sub dialog box says: Error signature szAppName : php-cgi.exe szAppVer : 5.3.0.0 szModName : php5ts.dll szModVer : 5.3.0.0 offset : 000cea5d The To view technical information about the error report sub sub dialog box contains: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\WERc9f6.dir00\php-cgi.exe.mdmp C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\WERc9f6.dir00\appcompat.txt My Apache 1.3 error log message shows: [Wed Mar 11 14:59:02 2009] [error] [client 127.0.0.1] Premature end of script headers: c:/program files/php/php-cgi.exe My PHP version is: PHP 5.3.0beta2-dev (cgi-fcgi) (built: Mar 11 2009 17:04:23) -- Edit bug report at http://bugs.php.net/?id=47627edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47627r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47627r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47627r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47627r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47627r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47627r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47627r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47627r=needscript Try newer version: http://bugs.php.net/fix.php?id=47627r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47627r=support Expected behavior: http://bugs.php.net/fix.php?id=47627r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47627r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47627r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47627r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47627r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47627r=dst IIS Stability: http://bugs.php.net/fix.php?id=47627r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47627r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47627r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47627r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47627r=mysqlcfg
#47629 [NEW]: mysqli connect timeout causes fatal error
From: danielc at analysisandsolutions dot com
Operating system: Windows XP SP3
PHP version: 5.3CVS-2009-03-12 (snap)
PHP Bug Type: MySQLi related
Bug description: mysqli connect timeout causes fatal error
Description:
A fatal error is generated if a MySQLi connection attempt times out AND
the default_socket_timeout ini setting is greater that the
max_execution_time ini setting. This is happening in PHP 5.3, Mar 11 2009
17:04:24, VC6 thread safe snapshot build.
This does not happen on timeouts when using socket_bind().
This does not happen in PHP 5.2.9-1.
Reproduce code:
---
// BOGUS MYSQL PORT NUMBER IS INTENTIONAL.
echo 'PHP ' . phpversion() . \n\n;
echo ONE ---\n;
ini_set('max_execution_time', 6);
ini_set('default_socket_timeout', 2);
echo 'max_execution_time: ' . ini_get('max_execution_time') . \n;
echo 'default_socket_timeout: ' . ini_get('default_socket_timeout') .
\n;
$mysqli = new mysqli('localhost', 'does', 'not', 'matter', 1);
if ($mysqli-connect_error) {
echo GOOD CATCH\n\n;
}
echo TWO ---\n;
ini_set('max_execution_time', 2);
ini_set('default_socket_timeout', 6);
echo 'max_execution_time: ' . ini_get('max_execution_time') . \n;
echo 'default_socket_timeout: ' . ini_get('default_socket_timeout') .
\n;
$mysqli = new mysqli('localhost', 'does', 'not', 'matter', 1);
if ($mysqli-connect_error) {
echo GOOD CATCH\n\n;
}
Expected result:
PHP 5.3.0beta2-dev
ONE ---
max_execution_time: 6
default_socket_timeout: 2
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected host has
failed to respond. in ...
GOOD CATCH
TWO ---
max_execution_time: 2
default_socket_timeout: 6
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected host has
failed to respond. in ...
GOOD CATCH
Actual result:
--
PHP 5.3.0beta2-dev
ONE ---
max_execution_time: 6
default_socket_timeout: 2
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected host has
failed to respond. in ...
GOOD CATCH
TWO ---
max_execution_time: 2
default_socket_timeout: 6
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected host has
failed to respond. in ...
Fatal error: Maximum execution time of 2 seconds exceeded in ...
--
Edit bug report at http://bugs.php.net/?id=47629edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47629r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47629r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47629r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47629r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47629r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47629r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47629r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47629r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47629r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47629r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47629r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47629r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47629r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47629r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47629r=php4
Daylight Savings:http
#47320 [NEW]: $php_errormsg out of scope in functions
From: danielc at analysisandsolutions dot com
Operating system:
PHP version: 5.3.0beta1
PHP Bug Type: Scripting Engine problem
Bug description: $php_errormsg out of scope in functions
Description:
The scope of $php_errormsg has changed in 5.3. It is no longer available
inside functions.
Perhaps this is intentional, perhaps not. If it is intentional, I
encourage the decision be changed to improve compatibility between
versions.
If it won't be changed, we need to update the 5.3 upgrade guide at
http://wiki.php.net/doc/scratchpad/upgrade/53.
Reproduce code:
---
if (!...@substr('no 2nd parameter')) {
echo '$php_errormsg in global: ' . $php_errormsg . \n;
}
function foo() {
if (!...@substr('no 2nd parameter')) {
echo '$php_errormsg in function: ' . $php_errormsg . \n;
echo '$GLOBALS[php_errormsg] in function: ' .
$GLOBALS['php_errormsg'] . \n;
}
}
foo();
Expected result:
$php_errormsg in global: substr() expects at least 2 parameters, 1 given
$php_errormsg in function: substr() expects at least 2 parameters, 1
given
$GLOBALS[php_errormsg] in function: substr() expects at least 2
parameters, 1 given
Actual result:
--
$php_errormsg in global: substr() expects at least 2 parameters, 1 given
Notice: Undefined variable: php_errormsg in
D:\webroot\ideasphp\Atest.html on line 10
$php_errormsg in function:
$GLOBALS[php_errormsg] in function: substr() expects at least 2
parameters, 1 given
--
Edit bug report at http://bugs.php.net/?id=47320edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47320r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47320r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47320r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47320r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47320r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47320r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47320r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47320r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47320r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47320r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47320r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47320r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47320r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47320r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47320r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47320r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47320r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47320r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47320r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47320r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47320r=mysqlcfg
#47320 [Fbk-Opn]: $php_errormsg out of scope in functions
ID: 47320
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.3.0beta1
New Comment:
Compared to 5.2.6.
Previous Comments:
[2009-02-05 23:45:07] j...@php.net
Compared to what version?
[2009-02-05 23:12:59] danielc at analysisandsolutions dot com
Description:
The scope of $php_errormsg has changed in 5.3. It is no longer
available inside functions.
Perhaps this is intentional, perhaps not. If it is intentional, I
encourage the decision be changed to improve compatibility between
versions.
If it won't be changed, we need to update the 5.3 upgrade guide at
http://wiki.php.net/doc/scratchpad/upgrade/53.
Reproduce code:
---
if (!...@substr('no 2nd parameter')) {
echo '$php_errormsg in global: ' . $php_errormsg . \n;
}
function foo() {
if (!...@substr('no 2nd parameter')) {
echo '$php_errormsg in function: ' . $php_errormsg . \n;
echo '$GLOBALS[php_errormsg] in function: ' .
$GLOBALS['php_errormsg'] . \n;
}
}
foo();
Expected result:
$php_errormsg in global: substr() expects at least 2 parameters, 1
given
$php_errormsg in function: substr() expects at least 2 parameters, 1
given
$GLOBALS[php_errormsg] in function: substr() expects at least 2
parameters, 1 given
Actual result:
--
$php_errormsg in global: substr() expects at least 2 parameters, 1
given
Notice: Undefined variable: php_errormsg in
D:\webroot\ideasphp\Atest.html on line 10
$php_errormsg in function:
$GLOBALS[php_errormsg] in function: substr() expects at least 2
parameters, 1 given
--
Edit this bug report at http://bugs.php.net/?id=47320edit=1
#44769 [Com]: declaring private magic methods should throw error
ID: 44769
Comment by: danielc at analysisandsolutions dot com
Reported By: todd at magnifisites dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.2.5
New Comment:
Marcus feels this is a bug and should be addressed
(http://news.php.net/php.internals/37857).
Once this is fixed, the documentation bug should be updated
(http://bugs.php.net/bug.php?id=43924).
Here are earlier bug reports covering this issue...
Documentation bugs that have been closed:
http://bugs.php.net/bug.php?id=31806
http://bugs.php.net/bug.php?id=40103
Illia marked this bogus saying it is the expected behavior.
http://bugs.php.net/bug.php?id=40056
Previous Comments:
[2008-04-17 23:15:57] todd at magnifisites dot com
Description:
When using object overloading I thought I might receive at the very
least a warning error if I attempted to declare any of the magic methods
as private in a class definition as per the documentation:
All overloading methods must be defined as public.
http://php.net/language.oop5.overloading.php
Also tested in PHP 6CVS-2008-04-17 (snap)
Reproduce code:
---
class MemberTest {
/** Location for overloaded data. */
private $data = array();
private function __set($name, $value) {
echo Setting '$name' to '$value'\n;
$this-data[$name] = $value;
}
private function __get($name) {
echo Getting '$name'\n;
if (array_key_exists($name, $this-data)) {
return $this-data[$name];
}
}
}
echo pre\n;
$obj = new MemberTest;
$obj-a = 1;
echo $obj-a . \n;
exit;
Expected result:
A FATAL error or at the very least a WARNING error with
error_reporting = E_ALL | E_STRICT
Actual result:
--
pre
Setting 'a' to '1'
Getting 'a'
1
--
Edit this bug report at http://bugs.php.net/?id=44769edit=1
#45089 [NEW]: __callStatic $name case sensitivity
From: danielc at analysisandsolutions dot com
Operating system:
PHP version: 5.3CVS-2008-05-26 (snap)
PHP Bug Type: Class/Object related
Bug description: __callStatic $name case sensitivity
Description:
The value of $name produced by __callStatic() is lower cased but the $name
produced by the regular __call() is unchanged.
Please adjust __callStatic() so it doesn't change the case of $name.
Reproduce code:
---
class MethodTest {
public static function __callStatic($name, $arguments) {
echo Calling static method '$name'
. implode(', ', $arguments). \n;
}
}
MethodTest::runTest('in static context');
Expected result:
Calling static method 'runTest' in static context
Actual result:
--
Calling static method 'runtest' in static context
--
Edit bug report at http://bugs.php.net/?id=45089edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45089r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45089r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45089r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45089r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45089r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45089r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45089r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45089r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45089r=support
Expected behavior:http://bugs.php.net/fix.php?id=45089r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45089r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45089r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45089r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45089r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45089r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45089r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45089r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45089r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45089r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45089r=mysqlcfg
#38558 [Csd-Opn]: [patch] run-tests.php: spaces in path
ID: 38558 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Closed +Status: Open Bug Type: Unknown/Other Function Operating System: Windows 2000 PHP Version: 5.2.0RC2 New Comment: Thanks for the prompt action, Tony. Here are patches for 5.1 and 5.0: http://www.analysisandsolutions.com/php/run-tests--pathspace-51.diff http://www.analysisandsolutions.com/php/run-tests--pathspace-50.diff Previous Comments: [2006-08-23 07:03:15] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Committed, thanks. [2006-08-23 04:25:38] danielc at analysisandsolutions dot com Description: run-tests.php doesn't account for spaces in the path to it. This oversight produces the following errors: Could not open input file: c:\Program (2 times) parse error, unexpected $end in Command line code on line 1 In addition, those errors cause $php_info section from parsing/outputting correctly. The following patch fixes it. http://www.analysisandsolutions.com/php/run-tests--pathspace.diff Thanks. -- Edit this bug report at http://bugs.php.net/?id=38558edit=1
#38558 [NEW]: [patch] run-tests.php: spaces in path
From: danielc at analysisandsolutions dot com Operating system: Windows 2000 PHP version: 5.2.0RC2 PHP Bug Type: Unknown/Other Function Bug description: [patch] run-tests.php: spaces in path Description: run-tests.php doesn't account for spaces in the path to it. This oversight produces the following errors: Could not open input file: c:\Program (2 times) parse error, unexpected $end in Command line code on line 1 In addition, those errors cause $php_info section from parsing/outputting correctly. The following patch fixes it. http://www.analysisandsolutions.com/php/run-tests--pathspace.diff Thanks. -- Edit bug report at http://bugs.php.net/?id=38558edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38558r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38558r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38558r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38558r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38558r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38558r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38558r=needscript Try newer version:http://bugs.php.net/fix.php?id=38558r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38558r=support Expected behavior:http://bugs.php.net/fix.php?id=38558r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38558r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38558r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38558r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38558r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38558r=dst IIS Stability:http://bugs.php.net/fix.php?id=38558r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38558r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38558r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38558r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38558r=mysqlcfg
#31979 [Bgs-Opn]: msql_fetch_field() not reporting unique keys
ID: 31979
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Bogus
+Status: Open
Bug Type: mSQL related
Operating System: NetBSD 2.0
PHP Version: 5CVS-2005-02-15
New Comment:
Jani, you can do better than that. Are you saying you ran my test and
got the expected result? Or are you passing the buck?
Previous Comments:
[2005-06-07 00:24:32] [EMAIL PROTECTED]
Apparently the msql version you've compiled PHP does not set the field
properly.
[2005-02-15 05:26:25] danielc at analysisandsolutions dot com
Description:
One of the properties returned by msql_fetch_field() is unique. It
is supposed to contain 1 if the column in question is part of a unique
key and 0 if it's not. But it always returns 0.
Reproduce code:
---
$con = msql_connect();
$db = msql_select_db('ptdb', $con);
msql_query('CREATE TABLE blah (i INT)', $con);
msql_query('CREATE UNIQUE INDEX bi ON blah (i)', $con);
$result = msql_query('SELECT * FROM blah', $con);
$info = msql_fetch_field($result);
print_r($info);
msql_query('DROP TABLE blah', $con);
Expected result:
stdClass Object
(
[name] = i
[table] = blah
[not_null] = 0
[unique] = 1
[type] = int
)
Actual result:
--
stdClass Object
(
[name] = i
[table] = blah
[not_null] = 0
[unique] = 0
[type] = int
)
--
Edit this bug report at http://bugs.php.net/?id=31979edit=1
#31960 [Opn]: PATCH: msql_fetch_row() and msql_fetch_array() dropping columns with NULL values
ID: 31960
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: mSQL related
Operating System: NetBSD 2.0
PHP Version: 5CVS-2005-02-13 (dev)
New Comment:
I also put together a patch for the PHP_4_3 branch:
http://www.analysisandsolutions.com/php/php_msql.c.bug31960.4_3.diff
It hasn't been tested, but looking at the source of the MySQL extension
makes me think it should work.
Though the script I put in the Reproduce code section above doesn't
test what happens with empty strings, I subsequently tested the
behavior and everything works fine.
Previous Comments:
[2005-02-15 02:36:44] danielc at analysisandsolutions dot com
I looked at the MySQL extension to see how they handled NULL values and
copied that into the mSQL extension. Here's the patch against head:
http://www.analysisandsolutions.com/php/php_msql.c.bug31960.diff
Works fine on my installation of 5.0.4-dev.
[2005-02-13 21:02:44] danielc at analysisandsolutions dot com
Description:
msql_fetch_row() and msql_fetch_array() silently drop columns that
contain NULL values. It's important to retrieve all data from a row,
even if it's NULL. oci8 does this just fine.
While there's a comment in the msql_fetch_array() documentation to
watch out for items that have NULL/0/'' values, it doesn't exactly say
what the problem is and it only talks about results that have only one
column.
Reproduce code:
---
$con = msql_connect();
$db = msql_select_db('ptdb', $con);
msql_query('CREATE TABLE blah (i INT, c CHAR(5))', $con);
msql_query(INSERT INTO blah VALUES (1, 'a'), $con);
msql_query(INSERT INTO blah VALUES (2, NULL), $con);
msql_query(INSERT INTO blah VALUES (NULL, 'c'), $con);
$result = msql_query('SELECT * FROM blah', $con);
while ($arr = msql_fetch_array($result, MSQL_ASSOC)) {
var_dump($arr);
echo \n;
}
msql_query('DROP TABLE blah', $con);
Expected result:
array(2) {
[i]=
string(1) 1
[c]=
string(1) a
}
array(2) {
[i]=
string(1) 2
[c]=
NULL
}
array(2) {
[a]=
NULL
[c]=
string(1) c
}
Actual result:
--
array(2) {
[i]=
string(1) 1
[c]=
string(1) a
}
array(1) {
[i]=
string(1) 2
}
array(1) {
[c]=
string(1) c
}
--
Edit this bug report at http://bugs.php.net/?id=31960edit=1
#31960 [Opn]: PATCH: msql_fetch_row() and msql_fetch_array() dropping columns with NULL values
ID: 31960
User updated by: danielc at analysisandsolutions dot com
-Summary: msql_fetch_row() and msql_fetch_array() dropping
columns with NULL values
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: mSQL related
Operating System: NetBSD 2.0
PHP Version: 5CVS-2005-02-13 (dev)
New Comment:
I looked at the MySQL extension to see how they handled NULL values and
copied that into the mSQL extension. Here's the patch against head:
http://www.analysisandsolutions.com/php/php_msql.c.bug31960.diff
Works fine on my installation of 5.0.4-dev.
Previous Comments:
[2005-02-13 21:02:44] danielc at analysisandsolutions dot com
Description:
msql_fetch_row() and msql_fetch_array() silently drop columns that
contain NULL values. It's important to retrieve all data from a row,
even if it's NULL. oci8 does this just fine.
While there's a comment in the msql_fetch_array() documentation to
watch out for items that have NULL/0/'' values, it doesn't exactly say
what the problem is and it only talks about results that have only one
column.
Reproduce code:
---
$con = msql_connect();
$db = msql_select_db('ptdb', $con);
msql_query('CREATE TABLE blah (i INT, c CHAR(5))', $con);
msql_query(INSERT INTO blah VALUES (1, 'a'), $con);
msql_query(INSERT INTO blah VALUES (2, NULL), $con);
msql_query(INSERT INTO blah VALUES (NULL, 'c'), $con);
$result = msql_query('SELECT * FROM blah', $con);
while ($arr = msql_fetch_array($result, MSQL_ASSOC)) {
var_dump($arr);
echo \n;
}
msql_query('DROP TABLE blah', $con);
Expected result:
array(2) {
[i]=
string(1) 1
[c]=
string(1) a
}
array(2) {
[i]=
string(1) 2
[c]=
NULL
}
array(2) {
[a]=
NULL
[c]=
string(1) c
}
Actual result:
--
array(2) {
[i]=
string(1) 1
[c]=
string(1) a
}
array(1) {
[i]=
string(1) 2
}
array(1) {
[c]=
string(1) c
}
--
Edit this bug report at http://bugs.php.net/?id=31960edit=1
#31979 [NEW]: msql_fetch_field() not reporting unique keys
From: danielc at analysisandsolutions dot com
Operating system: NetBSD 2.0
PHP version: 5CVS-2005-02-15 (dev)
PHP Bug Type: mSQL related
Bug description: msql_fetch_field() not reporting unique keys
Description:
One of the properties returned by msql_fetch_field() is unique. It is
supposed to contain 1 if the column in question is part of a unique key
and 0 if it's not. But it always returns 0.
Reproduce code:
---
$con = msql_connect();
$db = msql_select_db('ptdb', $con);
msql_query('CREATE TABLE blah (i INT)', $con);
msql_query('CREATE UNIQUE INDEX bi ON blah (i)', $con);
$result = msql_query('SELECT * FROM blah', $con);
$info = msql_fetch_field($result);
print_r($info);
msql_query('DROP TABLE blah', $con);
Expected result:
stdClass Object
(
[name] = i
[table] = blah
[not_null] = 0
[unique] = 1
[type] = int
)
Actual result:
--
stdClass Object
(
[name] = i
[table] = blah
[not_null] = 0
[unique] = 0
[type] = int
)
--
Edit bug report at http://bugs.php.net/?id=31979edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31979r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31979r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31979r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31979r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31979r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31979r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31979r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31979r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31979r=support
Expected behavior: http://bugs.php.net/fix.php?id=31979r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31979r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31979r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31979r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31979r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31979r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31979r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31979r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31979r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31979r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31979r=mysqlcfg
#31960 [NEW]: msql_fetch_row() and msql_fetch_array() dropping columns with NULL values
From: danielc at analysisandsolutions dot com
Operating system: NetBSD 2.0
PHP version: 5CVS-2005-02-13 (dev)
PHP Bug Type: mSQL related
Bug description: msql_fetch_row() and msql_fetch_array() dropping columns with
NULL values
Description:
msql_fetch_row() and msql_fetch_array() silently drop columns that contain
NULL values. It's important to retrieve all data from a row, even if it's
NULL. oci8 does this just fine.
While there's a comment in the msql_fetch_array() documentation to watch
out for items that have NULL/0/'' values, it doesn't exactly say what the
problem is and it only talks about results that have only one column.
Reproduce code:
---
$con = msql_connect();
$db = msql_select_db('ptdb', $con);
msql_query('CREATE TABLE blah (i INT, c CHAR(5))', $con);
msql_query(INSERT INTO blah VALUES (1, 'a'), $con);
msql_query(INSERT INTO blah VALUES (2, NULL), $con);
msql_query(INSERT INTO blah VALUES (NULL, 'c'), $con);
$result = msql_query('SELECT * FROM blah', $con);
while ($arr = msql_fetch_array($result, MSQL_ASSOC)) {
var_dump($arr);
echo \n;
}
msql_query('DROP TABLE blah', $con);
Expected result:
array(2) {
[i]=
string(1) 1
[c]=
string(1) a
}
array(2) {
[i]=
string(1) 2
[c]=
NULL
}
array(2) {
[a]=
NULL
[c]=
string(1) c
}
Actual result:
--
array(2) {
[i]=
string(1) 1
[c]=
string(1) a
}
array(1) {
[i]=
string(1) 2
}
array(1) {
[c]=
string(1) c
}
--
Edit bug report at http://bugs.php.net/?id=31960edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31960r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31960r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31960r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31960r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31960r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31960r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31960r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31960r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31960r=support
Expected behavior: http://bugs.php.net/fix.php?id=31960r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31960r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31960r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31960r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31960r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31960r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31960r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31960r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31960r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31960r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31960r=mysqlcfg
#29733 [Com]: printf handles repeated placeholders wrong
ID: 29733
Comment by: danielc at analysisandsolutions dot com
Reported By: bugs dot php dot net at bluetwanger dot de
Status: Open
Bug Type:Strings related
PHP Version: 5.0.1
New Comment:
Note, the error only happens when mixing numbered and non-numberd
directives. Tweaking the example from the original bug report to use
only numbered directives eliminates the error:
printf('%1$s - %2$s %3$s %3$s %2$s', 1, 2, 3);
Previous Comments:
[2004-08-27 14:36:16] bugs dot php dot net at bluetwanger dot de
Here's a link:
http://www.bluetwanger.de/~mbertheau/formatted_print.c.patch
You make it really hard to submit a patch. This bug thing has no
provision for attaching a file and you have to strain a lot to get at
an email address of a developer mailing list.
[2004-08-27 14:30:33] bugs dot php dot net at bluetwanger dot de
Here's a patch:
--- ext/standard/formatted_print.c.orig 2004-07-18 19:28:04.0
+0200
+++ ext/standard/formatted_print.c 2004-08-27 14:23:07.580732341
+0200
@@ -537,12 +537,6 @@
php_sprintf_appendchar(result, outpos, size,
'%' TSRMLS_CC);
inpos += 2;
} else {
- if (currarg = argc format[inpos + 1] !=
'%') {
- efree(result);
- efree(args);
- php_error_docref(NULL TSRMLS_CC,
E_WARNING, Too few arguments);
- return NULL;
- }
/* starting a new format specifier, reset
variables */
alignment = ALIGN_RIGHT;
adjusting = 0;
@@ -574,13 +568,6 @@
argnum += format_offset;
- if (argnum = argc) {
- efree(result);
- efree(args);
- php_error_docref(NULL
TSRMLS_CC, E_WARNING, Too few arguments);
- return NULL;
- }
-
/* after argnum comes modifiers */
PRINTF_DEBUG((sprintf: looking for
modifiers\n
sprintf: now
looking at '%c', inpos=%d\n,
@@ -635,6 +622,13 @@
argnum = currarg++ + format_offset;
}
+if (argnum = argc) {
+efree(result);
+efree(args);
+php_error_docref(NULL TSRMLS_CC, E_WARNING, Too few
arguments);
+return NULL;
+}
+
if (format[inpos] == 'l') {
inpos++;
}
Let's see if the line breaks survive.
It basically removes the bogus (format[inpos + 1] != '%' will always be
true there) arg number check and moves the right one outside the special
case for complicated format specifiers.
[2004-08-18 14:46:41] bugs dot php dot net at bluetwanger dot de
Description:
printf('%s - %s %s %3$s %2$s', 1, 2, 3);
complains:
Warning: printf(): Too few arguments in /home/bertheau/printf.php on
line 2
printf('%s - %s %s %3$s %2$s', 1, 2, 3, 4);
does not complain and prints:
1 - 2 3 3 2
I expect the first version to not complain and print what the second
version prints.
--
Edit this bug report at http://bugs.php.net/?id=29733edit=1
#30184 [Bgs]: run-tests error_reporting / ~E_STRICT ignored in phpt files
ID: 30184
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Win 2000
PHP Version: 5CVS-2004-09-21 (dev)
New Comment:
Andi:
Thanks for the --INI-- tip.
Regarding your first email which said make sure that E_STRICT is
turned off in the INI, php.ini already had reporting set to E_ALL but
it's being ignored.
The reason I posted it as a bug was this issue seems to have only arose
in the recent past. This issue hadn't come up while I was developing DB
and HTML_Form even though I've been running snapshots of PHP 5 for a
long while.
Thanks again.
Previous Comments:
[2004-09-22 23:43:23] [EMAIL PROTECTED]
And you should use an --INI-- section in your test file for this
anyway.
[2004-09-22 23:04:31] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Certain E_STRICT notices (such as var being deprecated) are emited at
compile-time therefore changing the error_reporting (which only happens
at run-time) will not affect it. You will need to make sure that
E_STRICT is turned off in the INI. One work around for the tests might
be to put the source in an include file and change error_reporting
before we include it. This issue was discussed on internals@ a few
months back and this behavior was agreed on because some of these
E_STRICT issues have to be detected at compile-time.
[2004-09-21 23:34:25] danielc at analysisandsolutions dot com
Something else to take into consideration is run-tests.php is
overriding the error_reporting settings from php.ini. This is causing
tests to fail even though the same tests worked fine under development
versions of PHP 5.
Here's a new set of test scripts...
=== s.phpt
--TEST--
error_reporting ignored for code in phpt
--SKIPIF--
--FILE--
?php
echo 'Default error_reporting in s.phpt: ' . error_reporting() . \n;
/*
* RESULT:
* Strict Standards: var: Deprecated. Please use the
* public/private/protected modifiers in s.php on line 28
* Default error_reporting in s.phpt: 4095
* The error_reporting in s.inc: 2047
* Subsequent error_reporting in s.phpt: 2047
*
* RESULT if error_reporting(E_ALL) is commented out:
* Strict Standards: var: Deprecated. Please use the
* public/private/protected modifiers in s.php on line 28
* Default error_reporting in s.phpt: 4095
* Strict Standards: var: Deprecated. Please use the
* public/private/protected modifiers in s.inc on line 6
* The error_reporting in s.inc: 4095
* Subsequent error_reporting in s.phpt: 4095
*/
error_reporting(E_ALL);
include './s.inc';
class phpt {
var $phpt_var;
}
echo 'Subsequent error_reporting in s.phpt: ' . error_reporting() .
\n;
?
--EXPECT--
Default error_reporting in s.phpt: 2047
The error_reporting in s.inc: 2047
Subsequent error_reporting in s.phpt: 2047
=== s.inc
?php
echo 'The error_reporting in s.inc: ' . error_reporting() . \n;
class inc {
var $inc_var;
}
[2004-09-21 19:39:19] danielc at analysisandsolutions dot com
Description:
Using:
* PHP 5.0.2RC1 (cli) (built: Sep 21 2004 10:29:26)
* run-tests.php version 1.195.2.1 or HEAD
When error_reporting is set to E_ALL in a .phpt file, E_STRICT warnings
still come up for code in the .phpt file. The notice isn't generated
for code in included files.
Reproduce code:
---
NOTE: two files...
=== s.phpt =
--TEST--
error_reporting ignored for code in phpt
--SKIPIF--
--FILE--
?php
/*
* error_reporting(E_ALL) is ignored for the code
* in this file but not the included file.
*/
error_reporting(E_ALL);
include './s.inc';
class phpt {
var $phpt_var;
}
?
--EXPECT--
=== s.inc =
?php
class inc {
var $inc_var;
}
Expected result:
Test to pass.
Actual result:
--
If error_reporting(E_ALL)
-
Strict Standards: var: Deprecated. Please use the
public/private/protected modifiers in s.php on line 12
If error_reporting(E_ALL) commented out
---
Strict Standards: var: Deprecated. Please use the
public/private/protected modifiers in s.php on line 12
Strict Standards: var: Deprecated. Please use the
public/private/protected modifiers in s.inc on line 4
#30184 [NEW]: run-tests error_reporting / ~E_STRICT ignored in phpt files
From: danielc at analysisandsolutions dot com
Operating system: Win 2000
PHP version: 5CVS-2004-09-21 (dev)
PHP Bug Type: Unknown/Other Function
Bug description: run-tests error_reporting / ~E_STRICT ignored in phpt files
Description:
Using:
* PHP 5.0.2RC1 (cli) (built: Sep 21 2004 10:29:26)
* run-tests.php version 1.195.2.1 or HEAD
When error_reporting is set to E_ALL in a .phpt file, E_STRICT warnings
still come up for code in the .phpt file. The notice isn't generated for
code in included files.
Reproduce code:
---
NOTE: two files...
=== s.phpt =
--TEST--
error_reporting ignored for code in phpt
--SKIPIF--
--FILE--
?php
/*
* error_reporting(E_ALL) is ignored for the code
* in this file but not the included file.
*/
error_reporting(E_ALL);
include './s.inc';
class phpt {
var $phpt_var;
}
?
--EXPECT--
=== s.inc =
?php
class inc {
var $inc_var;
}
Expected result:
Test to pass.
Actual result:
--
If error_reporting(E_ALL)
-
Strict Standards: var: Deprecated. Please use the public/private/protected
modifiers in s.php on line 12
If error_reporting(E_ALL) commented out
---
Strict Standards: var: Deprecated. Please use the public/private/protected
modifiers in s.php on line 12
Strict Standards: var: Deprecated. Please use the public/private/protected
modifiers in s.inc on line 4
--
Edit bug report at http://bugs.php.net/?id=30184edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30184r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30184r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30184r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30184r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30184r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30184r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30184r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30184r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30184r=support
Expected behavior: http://bugs.php.net/fix.php?id=30184r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30184r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30184r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30184r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30184r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30184r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30184r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30184r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30184r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30184r=mysqlcfg
#30184 [Opn]: run-tests error_reporting / ~E_STRICT ignored in phpt files
ID: 30184
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: Unknown/Other Function
Operating System: Win 2000
PHP Version: 5CVS-2004-09-21 (dev)
New Comment:
Something else to take into consideration is run-tests.php is
overriding the error_reporting settings from php.ini. This is causing
tests to fail even though the same tests worked fine under development
versions of PHP 5.
Here's a new set of test scripts...
=== s.phpt
--TEST--
error_reporting ignored for code in phpt
--SKIPIF--
--FILE--
?php
echo 'Default error_reporting in s.phpt: ' . error_reporting() . \n;
/*
* RESULT:
* Strict Standards: var: Deprecated. Please use the
* public/private/protected modifiers in s.php on line 28
* Default error_reporting in s.phpt: 4095
* The error_reporting in s.inc: 2047
* Subsequent error_reporting in s.phpt: 2047
*
* RESULT if error_reporting(E_ALL) is commented out:
* Strict Standards: var: Deprecated. Please use the
* public/private/protected modifiers in s.php on line 28
* Default error_reporting in s.phpt: 4095
* Strict Standards: var: Deprecated. Please use the
* public/private/protected modifiers in s.inc on line 6
* The error_reporting in s.inc: 4095
* Subsequent error_reporting in s.phpt: 4095
*/
error_reporting(E_ALL);
include './s.inc';
class phpt {
var $phpt_var;
}
echo 'Subsequent error_reporting in s.phpt: ' . error_reporting() .
\n;
?
--EXPECT--
Default error_reporting in s.phpt: 2047
The error_reporting in s.inc: 2047
Subsequent error_reporting in s.phpt: 2047
=== s.inc
?php
echo 'The error_reporting in s.inc: ' . error_reporting() . \n;
class inc {
var $inc_var;
}
Previous Comments:
[2004-09-21 19:39:19] danielc at analysisandsolutions dot com
Description:
Using:
* PHP 5.0.2RC1 (cli) (built: Sep 21 2004 10:29:26)
* run-tests.php version 1.195.2.1 or HEAD
When error_reporting is set to E_ALL in a .phpt file, E_STRICT warnings
still come up for code in the .phpt file. The notice isn't generated
for code in included files.
Reproduce code:
---
NOTE: two files...
=== s.phpt =
--TEST--
error_reporting ignored for code in phpt
--SKIPIF--
--FILE--
?php
/*
* error_reporting(E_ALL) is ignored for the code
* in this file but not the included file.
*/
error_reporting(E_ALL);
include './s.inc';
class phpt {
var $phpt_var;
}
?
--EXPECT--
=== s.inc =
?php
class inc {
var $inc_var;
}
Expected result:
Test to pass.
Actual result:
--
If error_reporting(E_ALL)
-
Strict Standards: var: Deprecated. Please use the
public/private/protected modifiers in s.php on line 12
If error_reporting(E_ALL) commented out
---
Strict Standards: var: Deprecated. Please use the
public/private/protected modifiers in s.php on line 12
Strict Standards: var: Deprecated. Please use the
public/private/protected modifiers in s.inc on line 4
--
Edit this bug report at http://bugs.php.net/?id=30184edit=1
#28999 [Opn]: exec()'s output array overwritten
ID: 28999
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: Unknown/Other Function
Operating System: Windows 2000
PHP Version: 5CVS-2004-07-03 (dev)
New Comment:
Curt Zirzow posted a patch for this to internals...
http://news.php.net/php.internals/10968
Previous Comments:
[2004-07-03 06:05:05] danielc at analysisandsolutions dot com
Description:
In PHP 4, when using exec() multiple times with the same array in the
output parameter, the data from subsequent exec() calls appended the
new results to the existing array. This is as the manual says.
When PHP 5 first came out, each call to exec() overwrote the prior
array. At some point a while ago, there was discussion on the list and
things were changed back to the old behavior.
At some point after that, the arrays started getting overwritten again.
Is this intentional?
I saw no notices about it in README.PHP4-TO-PHP5-THIN-CHANGES or in the
man page.
Can the old behavior be reimplemented in order to preserve
compatibility?
I made a post about this to internals:
http://marc.theaimsgroup.com/?l=php-devm=108874256229775w=2
Reproduce code:
---
?php
exec('date', $Return);
exec('date', $Return);
print_r($Return);
?
Expected result:
Array
(
[0] = The current date is: Fri 07/02/2004
[1] = Enter the new date: (mm-dd-yy)
[2] = The current date is: Fri 07/02/2004
[3] = Enter the new date: (mm-dd-yy)
)
Actual result:
--
Array
(
[0] = The current date is: Fri 07/02/2004
[1] = Enter the new date: (mm-dd-yy)
)
--
Edit this bug report at http://bugs.php.net/?id=28999edit=1
#28999 [NEW]: exec()'s output array overwritten
From: danielc at analysisandsolutions dot com
Operating system: Windows 2000
PHP version: 5CVS-2004-07-03 (dev)
PHP Bug Type: Unknown/Other Function
Bug description: exec()'s output array overwritten
Description:
In PHP 4, when using exec() multiple times with the same array in the
output parameter, the data from subsequent exec() calls appended the new
results to the existing array. This is as the manual says.
When PHP 5 first came out, each call to exec() overwrote the prior array.
At some point a while ago, there was discussion on the list and things
were changed back to the old behavior.
At some point after that, the arrays started getting overwritten again. Is
this intentional?
I saw no notices about it in README.PHP4-TO-PHP5-THIN-CHANGES or in the
man page.
Can the old behavior be reimplemented in order to preserve compatibility?
I made a post about this to internals:
http://marc.theaimsgroup.com/?l=php-devm=108874256229775w=2
Reproduce code:
---
?php
exec('date', $Return);
exec('date', $Return);
print_r($Return);
?
Expected result:
Array
(
[0] = The current date is: Fri 07/02/2004
[1] = Enter the new date: (mm-dd-yy)
[2] = The current date is: Fri 07/02/2004
[3] = Enter the new date: (mm-dd-yy)
)
Actual result:
--
Array
(
[0] = The current date is: Fri 07/02/2004
[1] = Enter the new date: (mm-dd-yy)
)
--
Edit bug report at http://bugs.php.net/?id=28999edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28999r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28999r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28999r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28999r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28999r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28999r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28999r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28999r=support
Expected behavior: http://bugs.php.net/fix.php?id=28999r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28999r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28999r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28999r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28999r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28999r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28999r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28999r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28999r=float
#28912 [Fbk-Opn]: MYSQLI_TYPE_STRING != mysqli_fetch_field() type for VARCHAR column
ID: 28912 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: Windows 2000 PHP Version: 5CVS-2004-06-24 (dev) New Comment: Documentation isn't involved. This is purely code. The type property returned from the function != the value of the constant. Perhaps your getting the right result is due to both of us running different versions of the software? Here's what I'm on: MySQL: Ver 14.5 Distrib 4.1.2-alpha, for Win95/Win98 (i32) PHP:PHP 5.0.0-dev (cli) (built: Jun 28 2004 16:29:27) Previous Comments: [2004-06-28 18:51:13] [EMAIL PROTECTED] Looks like a documentation problem. However I couldn't find this in documentation. Also the example output in mysqli_fetch_field returns 254. Could you please give me a link to the wrong documentation? [2004-06-24 18:50:07] danielc at analysisandsolutions dot com Description: The type value returned from mysqli_fetch_field() for a VARCHAR field is 253. The manual says the constant for VARCHAR fields is MYSQLI_TYPE_STRING which has a value of 254. So, there's no way to determine column types via constants for VARCHAR's. Reproduce code: --- mysqli_query($db-connection, 'CREATE TABLE bar (Cf VARCHAR(5))'); $r = mysqli_query($db-connection, 'SELECT Cf FROM bar'); $tmp = mysqli_fetch_field($r); echo type found = $tmp-type\n; echo 'MYSQLI_TYPE_STRING = ' . MYSQLI_TYPE_STRING . \n; mysqli_query($db-connection, 'DROP TABLE bar'); Expected result: type found = 254 MYSQLI_TYPE_STRING = 254 Actual result: -- type found = 253 MYSQLI_TYPE_STRING = 254 -- Edit this bug report at http://bugs.php.net/?id=28912edit=1
#28912 [Bgs-Opn]: MYSQLI_TYPE_STRING != mysqli_fetch_field() type for VARCHAR column
ID: 28912 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Bogus +Status: Open Bug Type: MySQL related Operating System: Windows 2000 PHP Version: 5CVS-2004-06-24 (dev) New Comment: Ah. Thanks for the clarification. Then phpdoc/en/reference/mysqli/constants.xml needs updating. You said: varchar column definition returns MYSQLI_TYPE_VAR_STRING, char column definition returns MYSQLI_TYPE_STRING. Though the docs say: MYSQLI_TYPE_STRING (integer) Field is defined as VARCHAR MYSQLI_TYPE_CHAR (integer) Field is defined as CHAR BUT, not so fast... CHAR columns return 253, but MYSQLI_TYPE_STRING's value is 254. And MYSQLI_TYPE_CHAR is defined, but what's it for? ?php mysqli_query($db-connection, 'CREATE TABLE bar (Vf VARCHAR(5),' . ' Cf CHAR(5))'); $r = mysqli_query($db-connection, 'SELECT Vf, Cf FROM bar'); $tmp = mysqli_fetch_field($r); echo $tmp-name type found = $tmp-type\n; echo 'MYSQLI_TYPE_VAR_STRING = ' . MYSQLI_TYPE_VAR_STRING . \n\n; $tmp = mysqli_fetch_field($r); echo $tmp-name type found = $tmp-type\n; echo 'MYSQLI_TYPE_STRING = ' . MYSQLI_TYPE_STRING . \n\n; echo So, what's this for?...\n; echo 'MYSQLI_TYPE_CHAR = ' . MYSQLI_TYPE_CHAR . \n; mysqli_query($db-connection, 'DROP TABLE bar'); ? vvv OUTPUT Vf type found = 253 MYSQLI_TYPE_VAR_STRING = 253 Cf type found = 253 MYSQLI_TYPE_STRING = 254 So, what's this for?... MYSQLI_TYPE_CHAR = 1 ^^^ Previous Comments: [2004-06-28 23:48:20] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php varchar column definition returns MYSQLI_TYPE_VAR_STRING, char column definition returns MYSQLI_TYPE_STRING. [2004-06-28 19:35:22] danielc at analysisandsolutions dot com Documentation isn't involved. This is purely code. The type property returned from the function != the value of the constant. Perhaps your getting the right result is due to both of us running different versions of the software? Here's what I'm on: MySQL: Ver 14.5 Distrib 4.1.2-alpha, for Win95/Win98 (i32) PHP:PHP 5.0.0-dev (cli) (built: Jun 28 2004 16:29:27) [2004-06-28 18:51:13] [EMAIL PROTECTED] Looks like a documentation problem. However I couldn't find this in documentation. Also the example output in mysqli_fetch_field returns 254. Could you please give me a link to the wrong documentation? [2004-06-24 18:50:07] danielc at analysisandsolutions dot com Description: The type value returned from mysqli_fetch_field() for a VARCHAR field is 253. The manual says the constant for VARCHAR fields is MYSQLI_TYPE_STRING which has a value of 254. So, there's no way to determine column types via constants for VARCHAR's. Reproduce code: --- mysqli_query($db-connection, 'CREATE TABLE bar (Cf VARCHAR(5))'); $r = mysqli_query($db-connection, 'SELECT Cf FROM bar'); $tmp = mysqli_fetch_field($r); echo type found = $tmp-type\n; echo 'MYSQLI_TYPE_STRING = ' . MYSQLI_TYPE_STRING . \n; mysqli_query($db-connection, 'DROP TABLE bar'); Expected result: type found = 254 MYSQLI_TYPE_STRING = 254 Actual result: -- type found = 253 MYSQLI_TYPE_STRING = 254 -- Edit this bug report at http://bugs.php.net/?id=28912edit=1
#28912 [NEW]: MYSQLI_TYPE_STRING != mysqli_fetch_field() type for VARCHAR column
From: danielc at analysisandsolutions dot com Operating system: Windows 2000 PHP version: 5CVS-2004-06-24 (dev) PHP Bug Type: MySQL related Bug description: MYSQLI_TYPE_STRING != mysqli_fetch_field() type for VARCHAR column Description: The type value returned from mysqli_fetch_field() for a VARCHAR field is 253. The manual says the constant for VARCHAR fields is MYSQLI_TYPE_STRING which has a value of 254. So, there's no way to determine column types via constants for VARCHAR's. Reproduce code: --- mysqli_query($db-connection, 'CREATE TABLE bar (Cf VARCHAR(5))'); $r = mysqli_query($db-connection, 'SELECT Cf FROM bar'); $tmp = mysqli_fetch_field($r); echo type found = $tmp-type\n; echo 'MYSQLI_TYPE_STRING = ' . MYSQLI_TYPE_STRING . \n; mysqli_query($db-connection, 'DROP TABLE bar'); Expected result: type found = 254 MYSQLI_TYPE_STRING = 254 Actual result: -- type found = 253 MYSQLI_TYPE_STRING = 254 -- Edit bug report at http://bugs.php.net/?id=28912edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28912r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28912r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28912r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28912r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28912r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28912r=needscript Try newer version: http://bugs.php.net/fix.php?id=28912r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28912r=support Expected behavior: http://bugs.php.net/fix.php?id=28912r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28912r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28912r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28912r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28912r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28912r=dst IIS Stability: http://bugs.php.net/fix.php?id=28912r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28912r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28912r=float
#28732 [NEW]: temp and tmp environment vars not registered via web
From: danielc at analysisandsolutions dot com
Operating system: windows 2000
PHP version: 4.3.7
PHP Bug Type: *General Issues
Bug description: temp and tmp environment vars not registered via web
Description:
Neither the TEMP or TMP environment variables show up via $_ENV, $_SERVER,
getenv() or phpinfo() when accessing scripts via a webserver (Apache
1.3.28). They're available when executing scripts via the command line
(both CGI and CLI).
FYI:
C:\PROGRA~1echo %temp%
C:\TEMP
C:\PROGRA~1echo %tmp%
C:\TEMP
Reproduce code:
---
?php
echo 'TEMP: ' . getenv('TEMP') . \n;
echo 'temp: ' . getenv('temp') . \n;
echo 'TMP: ' . getenv('TMP') . \n;
echo 'tmp: ' . getenv('tmp') . \n;
?
Expected result:
TEMP: C:\TEMP
temp: C:\TEMP
TMP: C:\TEMP
tmp: C:\TEMP
Actual result:
--
=== Via web server ===
TEMP:
temp:
TMP:
tmp:
=== Via command line ===
TEMP: C:\TEMP
temp: C:\TEMP
TMP: C:\TEMP
tmp: C:\TEMP
--
Edit bug report at http://bugs.php.net/?id=28732edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28732r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28732r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28732r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28732r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28732r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28732r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28732r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28732r=support
Expected behavior: http://bugs.php.net/fix.php?id=28732r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28732r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28732r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28732r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28732r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28732r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28732r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28732r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28732r=float
#28732 [Opn]: temp and tmp environment vars not registered via web
ID: 28732
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: *General Issues
Operating System: windows 2000
PHP Version: 4.3.7
New Comment:
Just to be 100% clear, PHP executes via CGI on the web server.
Previous Comments:
[2004-06-10 20:16:21] danielc at analysisandsolutions dot com
Description:
Neither the TEMP or TMP environment variables show up via $_ENV,
$_SERVER, getenv() or phpinfo() when accessing scripts via a webserver
(Apache 1.3.28). They're available when executing scripts via the
command line (both CGI and CLI).
FYI:
C:\PROGRA~1echo %temp%
C:\TEMP
C:\PROGRA~1echo %tmp%
C:\TEMP
Reproduce code:
---
?php
echo 'TEMP: ' . getenv('TEMP') . \n;
echo 'temp: ' . getenv('temp') . \n;
echo 'TMP: ' . getenv('TMP') . \n;
echo 'tmp: ' . getenv('tmp') . \n;
?
Expected result:
TEMP: C:\TEMP
temp: C:\TEMP
TMP: C:\TEMP
tmp: C:\TEMP
Actual result:
--
=== Via web server ===
TEMP:
temp:
TMP:
tmp:
=== Via command line ===
TEMP: C:\TEMP
temp: C:\TEMP
TMP: C:\TEMP
tmp: C:\TEMP
--
Edit this bug report at http://bugs.php.net/?id=28732edit=1
#28478 [NEW]: won't build: 'convert_scalar_to_number' : too few actual parameters
From: danielc at analysisandsolutions dot com Operating system: win PHP version: 4CVS-2004-05-21 (stable) PHP Bug Type: Sybase-ct (ctlib) related Bug description: won't build: 'convert_scalar_to_number' : too few actual parameters Description: I downloaded the latest PHP 4 windows snapshot and found php_sybase_ct.dll isn't in the extensions directory. The compile log shows... Compiling... php_sybase_ct.c c:\php4build\snap\ext\sybase_ct\php_sybase_ct.c(1136) : error C2198: 'convert_scalar_to_number' : too few actual parameters (from http://snaps.php.net/win32/compile-STABLE.log) -- Edit bug report at http://bugs.php.net/?id=28478edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28478r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28478r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28478r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28478r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28478r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28478r=needscript Try newer version: http://bugs.php.net/fix.php?id=28478r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28478r=support Expected behavior: http://bugs.php.net/fix.php?id=28478r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28478r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28478r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28478r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28478r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28478r=dst IIS Stability: http://bugs.php.net/fix.php?id=28478r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28478r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28478r=float
#28354 [Com]: sybase_free_result crash
ID: 28354
Comment by: danielc at analysisandsolutions dot com
Reported By: alahaye at fmlogistic dot com
Status: Open
Bug Type: Sybase-ct (ctlib) related
Operating System: Linux RadHat 7
PHP Version: 4.3.6
New Comment:
I'm experienceing this on Windows builds as well. The problem arose
some time between these two snapshots:
works php4-win32-STABLE-200401210130
crashes php4-win32-STABLE-200402161330
Previous Comments:
[2004-05-19 13:55:05] alahaye at fmlogistic dot com
Here the backtrace
(gdb) bt
#0 0x40ba7df0 in chunk_free (ar_ptr=0x40c50f00, p=0x8436518) at
malloc.c:3131
#1 0x40ba7d59 in __libc_free (mem=0x84368e8) at malloc.c:3054
#2 0x0816ed49 in shutdown_memory_manager (silent=0, clean_cache=0) at
/users/sources/php/php-4.3.6/Zend/zend_alloc.c:492
#3 0x08154c44 in php_request_shutdown (dummy=0x0) at
/users/sources/php/php-4.3.6/main/main.c:1003
#4 0x0819870d in main (argc=2, argv=0xb70c) at
/users/sources/php/php-4.3.6/sapi/cli/php_cli.c:873
#5 0x40b44177 in __libc_start_main (main=0x8197bd4 main, argc=2,
ubp_av=0xb70c, init=0x8086330 _init, fini=0x82500c0 _fini,
rtld_fini=0x4000e184 _dl_fini, stack_end=0xb6fc) at
../sysdeps/generic/libc-start.c:129
[2004-05-18 01:00:03] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2004-05-11 14:01:18] sergio dot zia at saipm dot com
I am encountering exactly the same problem :-(
Linux RedHat AS 2.1
PHP 4.3.6
[2004-05-10 22:55:49] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
[2004-05-10 22:28:19] alahaye at fmlogistic dot com
Description:
When using sybase_free_result, apache Segmentation fault.
PB doesn't exist with PHP 4.3.4.
Reproduce code:
---
?
$query = EXEC MyPROC;
$id = sybase_connect(SERVER,LOGIN,PASSWORD);
sybase_select_db(BASE,$id);
$result = sybase_query($query,$id);
While ($row = sybase_fetch_row ($result))
{
print $row[0].BR;
}
sybase_free_result($result);
sybase_close($id);
?
Expected result:
result of stored procedure
--
Edit this bug report at http://bugs.php.net/?id=28354edit=1
#28229 [NEW]: PATCH run-tests tripped up by spaces in names
From: danielc at analysisandsolutions dot com Operating system: Windows PHP version: 5CVS-2004-04-30 (dev) PHP Bug Type: Unknown/Other Function Bug description: PATCH run-tests tripped up by spaces in names Description: While running tests on my Windows machine I ran into a problem with run-tests.php. .phpt files which have spaces in their names/paths cause the tests to fail. The .out file contains text along the lines of Could not open C:\Programs As you can guess, the .phpt files were in a subdirectory of c:\program files\. The following patch places quotes around the file names when creating the $cmd: http://www.analysisandsolutions.com/php/run-tests.spaceinfilename.diff -- Edit bug report at http://bugs.php.net/?id=28229edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28229r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28229r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28229r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28229r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28229r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28229r=needscript Try newer version: http://bugs.php.net/fix.php?id=28229r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28229r=support Expected behavior: http://bugs.php.net/fix.php?id=28229r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28229r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28229r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28229r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28229r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28229r=dst IIS Stability: http://bugs.php.net/fix.php?id=28229r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28229r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28229r=float
#25987 [Com]: php and xml tag confusion
ID: 25987 Comment by: danielc at analysisandsolutions dot com Reported By: tkwright_233 at hotmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: * PHP Version: * New Comment: This needlessly causes problems for users. It would be nice to fix it, please. tkwright_233 seems on target when they say: PHP knows the diffrence of '?=' from '?'. so why can't it detect the diffrence of '?' from '?xml'? Thanks. Previous Comments: [2003-11-04 17:09:53] tkwright_233 at hotmail dot com what just happened? it appears some comments were lost(about 2-4). __ Anyway, it DOES know the diffrence of '?=' from '?'. so why can't it detect the diffrence of '?' from '?xml'? And, according to my brain, and museum.php.net, the deafult opining tag was changed from '?' to ?php' partially for this reason(and the closing tag from '' to '?'), from v.2 to v.4 . [2003-10-26 15:24:32] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php It does recognize the difference, if you disable short_tags, which you should for exactly this reason. [2003-10-25 15:18:05] [EMAIL PROTECTED] Short tags = '?'. That matches '?php' as well as '?=' or '?xml'. [2003-10-25 14:13:23] tkwright_233 at hotmail dot com Description: when an xml 'starting' tag is placed on an document, php confuses it with its opining and closing tag. it confuses its closing tag with xml end of the tag, and php confuses the open tag for php with the start of the tag declaring an xml document. Parse error: parse error, unexpected T_STRING in c:/apache/htdocs/xml.php on line 1 currently, the workaround is: ?php echo''.'?'.'x'.'m'.'l vers'.'ion=1'.'.'.'0'.' en'.'codi'.'ng=UT'.'F-8'.''.'?'.''.\n;? Reproduce code: --- ?xml version=1.0 encoding=UTF-8? Expected result: [no error],rest of page Actual result: -- Parse error: parse error, unexpected T_STRING in c:/apache/htdocs/xml.php on line 1 -- Edit this bug report at http://bugs.php.net/?id=25987edit=1
#27368 [NEW]: php.ini-(dist|recommended) have CR at end
From: danielc at analysisandsolutions dot com Operating system: Windows 2000 PHP version: 5CVS-2004-02-23 (dev) PHP Bug Type: *Configuration Issues Bug description: php.ini-(dist|recommended) have CR at end Description: Minor problem... The php.ini-dist and php.ini-recommended files in the latest Windows snapshot (php5-win32-200402231530) are in Unix format, but have a CR thrown in at the end of each file: ... snip ... ; tab-width: 4 ; End ^ here -- Edit bug report at http://bugs.php.net/?id=27368edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27368r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27368r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27368r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27368r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27368r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27368r=needscript Try newer version: http://bugs.php.net/fix.php?id=27368r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27368r=support Expected behavior: http://bugs.php.net/fix.php?id=27368r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27368r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27368r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27368r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27368r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27368r=dst IIS Stability: http://bugs.php.net/fix.php?id=27368r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27368r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27368r=float
#27368 [Bgs-Opn]: php.ini-(dist|recommended) have CR at end
ID: 27368 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Bogus +Status: Open Bug Type: *Configuration Issues Operating System: Windows 2000 PHP Version: 5CVS-2004-02-23 (dev) New Comment: Where were you looking? In CVS or in the files distributed in a php5-win32-200402231530 snapshot? They are definitely there in the snapshot. I can email you the files if you don't believe me. This may be due to the new build system, which when it went into effect threw in loads of CR's even though the raw files in CVS were fine. I posted a note to internals and it seems someone fixed something to make all but one of the CR's disappeared. Previous Comments: [2004-02-23 13:17:01] [EMAIL PROTECTED] In CVS: ; tab-width: 4 ; End: (there is no CR there) [2004-02-23 12:23:31] danielc at analysisandsolutions dot com Description: Minor problem... The php.ini-dist and php.ini-recommended files in the latest Windows snapshot (php5-win32-200402231530) are in Unix format, but have a CR thrown in at the end of each file: ... snip ... ; tab-width: 4 ; End ^ here -- Edit this bug report at http://bugs.php.net/?id=27368edit=1
#27123 [NEW]: casting arrays to objects and back
From: danielc at analysisandsolutions dot com
Operating system: Windows 2000 and OS X 10.3
PHP version: 5CVS-2004-02-03 (dev)
PHP Bug Type: Reproducible crash
Bug description: casting arrays to objects and back
Description:
Found PEAR DB's getAssoc() method didn't work correctly when in
DB_FETCHMODE_OBJECT mode. See pear/DB/tests/18get.phpt for that.
I pared it down a bit and then Adam Trachtenberg whittled it down even
farther. Here's what he found:
1) Use an array with a string key: array('a' = 1)
2) Cast it to an object and call get_object_vars()
on the result.
3) Assign this cast object to an array with
multiple elements.
4) Call print_r() on the resulting array.
If I remove any of these, the crash goes away.
Reproduce code:
---
?php
$array = array(1);
$element = (object) array('a' = 1);
get_object_vars($element);
$array[] = $element;
print_r($array);
?
Expected result:
Array
(
[0] = 1
[1] = stdClass Object
(
[a] = 1
)
)
Actual result:
--
~ WINDOWS 2000 ~
Array
(
[0] = 1
[1] = stdClass Object
(
[a] = 1130656883
)
)
~ OS X 10.3, PHP = beta 3 ~
No Output.
~ OS X 10.3, PHP = recent CVS ~
Array
(
[0] = 1
[2] = stdClass Object
(
[a] =
... backtrace ...
#0 0x00271308 in _zend_is_inconsistent (ht=0x5a5a5a5a, file=0x3183f8
/usr/local/cvs/php/php-src/Zend/zend_hash.c, line=504) at
/usr/local/cvs/php/php-src/Zend/zend_hash.c:53
#1 0x00273384 in zend_hash_destroy (ht=0x5a5a5a5a) at
/usr/local/cvs/php/php-src/Zend/zend_hash.c:504
#2 0x002658a8 in _zval_dtor (zvalue=0xbfffe710, __zend_filename=0x3178bc
/usr/local/cvs/php/php-src/Zend/zend_operators.c, __zend_lineno=510) at
/usr/local/cvs/php/php-src/Zend/zend_variables.c:52
#3 0x0025d240 in _convert_to_string (op=0xbfffe710,
__zend_filename=0x317b5c /usr/local/cvs/php/php-src/Zend/zend.c,
__zend_lineno=256) at
/usr/local/cvs/php/php-src/Zend/zend_operators.c:510
#4 0x0026691c in zend_make_printable_zval (expr=0xace8d0,
expr_copy=0xbfffe710, use_copy=0xbfffe720) at
/usr/local/cvs/php/php-src/Zend/zend.c:256
#5 0x002669dc in zend_print_zval_ex (write_func=0x208fa0
php_body_write_wrapper, expr=0xace8d0, indent=0) at
/usr/local/cvs/php/php-src/Zend/zend.c:275
#6 0x00266984 in zend_print_zval (expr=0xace8d0, indent=0) at
/usr/local/cvs/php/php-src/Zend/zend.c:266
#7 0x00265d24 in zend_print_variable (var=0xace8d0) at
/usr/local/cvs/php/php-src/Zend/zend_variables.c:171
#8 0x00267094 in zend_print_zval_r_ex (write_func=0x208fa0
php_body_write_wrapper, expr=0xace8d0, indent=16) at
/usr/local/cvs/php/php-src/Zend/zend.c:387
#9 0x00266dc8 in zend_print_zval_r (expr=0xace8d0, indent=16) at
/usr/local/cvs/php/php-src/Zend/zend.c:342
#10 0x002662c8 in print_hash (ht=0xace860, indent=12, is_object=1 '\001')
at /usr/local/cvs/php/php-src/Zend/zend.c:159
#11 0x00267074 in zend_print_zval_r_ex (write_func=0x208fa0
php_body_write_wrapper, expr=0xacea48, indent=8) at
/usr/local/cvs/php/php-src/Zend/zend.c:381
#12 0x00266dc8 in zend_print_zval_r (expr=0xacea48, indent=8) at
/usr/local/cvs/php/php-src/Zend/zend.c:342
#13 0x002662c8 in print_hash (ht=0xacde60, indent=4, is_object=0 '\0') at
/usr/local/cvs/php/php-src/Zend/zend.c:159
#14 0x00266ed4 in zend_print_zval_r_ex (write_func=0x208fa0
php_body_write_wrapper, expr=0xacc538, indent=0) at
/usr/local/cvs/php/php-src/Zend/zend.c:356
#15 0x00266dc8 in zend_print_zval_r (expr=0xacc538, indent=0) at
/usr/local/cvs/php/php-src/Zend/zend.c:342
#16 0x00165a10 in zif_print_r (ht=1, return_value=0xacea98, this_ptr=0x0,
return_value_used=0) at
/usr/local/cvs/php/php-src/ext/standard/basic_functions.c:2570
#17 0x0029d5ac in zend_do_fcall_common_helper (execute_data=0xbfffecb0,
op_array=0xacdda8) at /usr/local/cvs/php/php-src/Zend/zend_execute.c:2550
#18 0x0029dff4 in zend_do_fcall_handler (execute_data=0xbfffecb0,
op_array=0xacdda8) at /usr/local/cvs/php/php-src/Zend/zend_execute.c:2697
#19 0x00297a20 in execute (op_array=0xacdda8) at
/usr/local/cvs/php/php-src/Zend/zend_execute.c:1264
#20 0x002689bc in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /usr/local/cvs/php/php-src/Zend/zend.c:1051
#21 0x00209bf8 in php_execute_script (primary_file=0xb720) at
/usr/local/cvs/php/php-src/main/main.c:1641
#22 0x002aac60 in main (argc=2, argv=0xbc94) at
/usr/local/cvs/php/php-src/sapi/cli/php_cli.c:939
--
Edit bug report at http://bugs.php.net/?id=27123edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27123r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27123r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27123r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27123r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27123r=needtrace
Need
#25724 [Com]: register_long_arrays breaks superglobals
ID: 25724 Comment by: danielc at analysisandsolutions dot com Reported By: kauer at face-online dot de Status: Verified Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2004-01-03 New Comment: Bug 26206 -- http://bugs.php.net/bug.php?id=26206 -- has been marked as a duplicate of this one. Previous Comments: [2004-01-21 02:05:14] [EMAIL PROTECTED] And both register_globals and register_long_arrays have to be off to reproduce this! [2004-01-21 02:03:44] [EMAIL PROTECTED] Only these superglobals are broken: $_SERVER $_ENV $_REQUEST All other work fine.. [2003-11-28 21:20:42] [EMAIL PROTECTED] Reproducable with this quick'n'dirty way too: # sapi/cli/php -d'register_long_arrays=off' -r 'var_dump($_SERVER);' [2003-10-02 04:55:56] kauer at face-online dot de Description: Using the binary from snaps.php.net, turning register_long_arrays off in .htaccess will make $_SERVER unavailable. Reproduce code: --- File: .htaccess php_flag register_long_arrays off PHP: var_dump($_SERVER); Expected result: I expect to see a variable dump of $_SERVER. Actual result: -- var_dump outputs NULL -- Edit this bug report at http://bugs.php.net/?id=25724edit=1
#26206 [Opn]: argv and argc not defined
ID: 26206
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: CGI related
Operating System: Windows 2000
PHP Version: 5CVS-2004-01-08
New Comment:
Greg just posted on the internals list that he too noticed that
$_SERVER['argv'] and $_SERVER['argc'] aren't set.
He also made a very interesting observation that $argv and $argc ARE
set.
EXAMPLE SCRIPT argvtest.php:
?php
var_dump($argv);
var_dump($_SERVER['argv']);
?
INVOCATION:
C:\PROGRA~1\phpphp argvtest.php 1 2
OUTPUT:
array(3) {
[0]=
string(12) argvtest.php
[1]=
string(1) 1
[2]=
string(1) 2
}
Notice: Undefined index: argv in C:\PROGRA~1\php\argvtest.php on line
3
NULL
Previous Comments:
[2004-01-08 13:14:25] danielc at analysisandsolutions dot com
No dice using php5-win32-200401081130
[2004-01-07 21:38:51] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Please try the latest snapshot.
[2003-12-01 13:57:39] danielc at analysisandsolutions dot com
Everything worked fine until I switched from
php5-win32-200310010230.zip to php5-win32-200311040330.zip
I will track down exactly which snapshot in this time period started
causing the problem. Then someone can examine the changes made in
order to isolate the problem.
Please inform me where I can find old snapshots to do this.
http://snaps.php.net/win32/ only has the most recent few.
[2003-12-01 13:31:20] [EMAIL PROTECTED]
Well, I can't reproduce this with either CLI or CGI, using either
php.ini-dist or php.ini-recommended. So there's something wrong with
your system, not PHP.
[2003-12-01 12:04:35] danielc at analysisandsolutions dot com
100% certain.
New PHP installs on this system are by moving the entirety of the old
install aside, extracting the contents of a new snapshot .zip file then
copying the exact files/structure over to the php directory. The
system finds the DLLS via the %path%, in which
C:\PROGRA~1\Php;C:\PROGRA~1\Php\dlls; are the first two entries.
The PHP DLL's have never been copied to any other location on this
computer.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/26206
--
Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26206 [Opn]: argv and argc not defined
ID: 26206
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: CGI related
Operating System: Windows 2000
PHP Version: 5CVS-2004-01-08
New Comment:
Here's a link to the discussion on the interals list back in October
about these changes:
http://marc.theaimsgroup.com/?t=10650930736r=1w=2
This is a link to the current discussion regarding the situation and
how either I'm misunderstanding things or things may not be working as
expected:
http://marc.theaimsgroup.com/?t=10743658311r=1w=2
Previous Comments:
[2004-01-17 14:17:35] danielc at analysisandsolutions dot com
Greg just posted on the internals list that he too noticed that
$_SERVER['argv'] and $_SERVER['argc'] aren't set.
He also made a very interesting observation that $argv and $argc ARE
set.
EXAMPLE SCRIPT argvtest.php:
?php
var_dump($argv);
var_dump($_SERVER['argv']);
?
INVOCATION:
C:\PROGRA~1\phpphp argvtest.php 1 2
OUTPUT:
array(3) {
[0]=
string(12) argvtest.php
[1]=
string(1) 1
[2]=
string(1) 2
}
Notice: Undefined index: argv in C:\PROGRA~1\php\argvtest.php on line
3
NULL
[2004-01-08 13:14:25] danielc at analysisandsolutions dot com
No dice using php5-win32-200401081130
[2004-01-07 21:38:51] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Please try the latest snapshot.
[2003-12-01 13:57:39] danielc at analysisandsolutions dot com
Everything worked fine until I switched from
php5-win32-200310010230.zip to php5-win32-200311040330.zip
I will track down exactly which snapshot in this time period started
causing the problem. Then someone can examine the changes made in
order to isolate the problem.
Please inform me where I can find old snapshots to do this.
http://snaps.php.net/win32/ only has the most recent few.
[2003-12-01 13:31:20] [EMAIL PROTECTED]
Well, I can't reproduce this with either CLI or CGI, using either
php.ini-dist or php.ini-recommended. So there's something wrong with
your system, not PHP.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/26206
--
Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26206 [Fbk-Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: No dice using php5-win32-200401081130 Previous Comments: [2004-01-07 21:38:51] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Please try the latest snapshot. [2003-12-01 13:57:39] danielc at analysisandsolutions dot com Everything worked fine until I switched from php5-win32-200310010230.zip to php5-win32-200311040330.zip I will track down exactly which snapshot in this time period started causing the problem. Then someone can examine the changes made in order to isolate the problem. Please inform me where I can find old snapshots to do this. http://snaps.php.net/win32/ only has the most recent few. [2003-12-01 13:31:20] [EMAIL PROTECTED] Well, I can't reproduce this with either CLI or CGI, using either php.ini-dist or php.ini-recommended. So there's something wrong with your system, not PHP. [2003-12-01 12:04:35] danielc at analysisandsolutions dot com 100% certain. New PHP installs on this system are by moving the entirety of the old install aside, extracting the contents of a new snapshot .zip file then copying the exact files/structure over to the php directory. The system finds the DLLS via the %path%, in which C:\PROGRA~1\Php;C:\PROGRA~1\Php\dlls; are the first two entries. The PHP DLL's have never been copied to any other location on this computer. [2003-12-01 03:25:23] [EMAIL PROTECTED] And you're absolutely sure you don't have ANY old PHP related dlls in your system before you installed the snapshot? (delete all php4ts.dll files..) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/26206 -- Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26791 [Opn]: mssql.textlimit and mssql.textsize can't be set via ini_set()
ID: 26791
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: MSSQL related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
Know what? The problem was where the ini_set() calls are made. They
must be done BEFORE the connection is established. Once it's made, it
can't be changed.
Oddly, it doesn't matter when one calls ini_set() for
mssql.datetimeconvert.
So, I'm not sure this bug report should be closed, called bogus or not.
It might be nice to have these work regardless of where they are
called. If no change is made, the behavior needs to be documented.
Couple things to keep in mind about my config:
Using CGI
Loading mssql via php.ini extensions
Versions 4.3.4 and php5-win32-200401081130 snapshot
Previous Comments:
[2004-01-08 00:12:28] [EMAIL PROTECTED]
This seams to be related to how the extension is loaded.
ini_set() works fine in php4 whn the extension is loaded from php.ini,
but not when dl() is used.
The dl() will also cause the output from phpinfo() to be incomplete!
[2004-01-06 18:56:04] [EMAIL PROTECTED]
Frank, nothing has changed in that function. Are you sure this really
works with PHP 5..?
[2004-01-05 02:44:12] [EMAIL PROTECTED]
This works in PHP5 but not in PHP4.3.x (tested on the cvs version). Did
something happen to the ini_set() funtion ?
[2004-01-05 01:34:58] danielc at analysisandsolutions dot com
Description:
The mssql.textlimit and mssql.textsize configuration options
can't be set via ini_set(). Changing them in php.ini works.
This is also the case in a recent PHP 5 snapshot
(500rc1-dev--php5-win32-200401022330).
This is the same issue as bug 20797 which was closed due to no
feedback.
SCRIPT CAN CHANGE LIMIT
===
php.ini
mssql.textlimit = 2147483647
mssql.textsize = 2147483647
script
SET TEXTSIZE 20
SCRIPT CAN'T CHANGE LIMIT
=
php.ini
mssql.textlimit = 20
mssql.textsize = 20
script
ini_set('mssql.textlimit', 2147483647);
ini_set('mssql.textsize', 2147483647);
php.ini
mssql.textlimit = 2147483647
mssql.textsize = 2147483647
script
ini_set('mssql.textlimit', 20);
ini_set('mssql.textsize', 20);
php.ini
; mssql.textlimit = 2147483647
; mssql.textsize = 2147483647
script
SET TEXTSIZE 2147483647
php.ini
mssql.textlimit = 20
mssql.textsize = 20
script
SET TEXTSIZE 2147483647
--
Edit this bug report at http://bugs.php.net/?id=26791edit=1
#26791 [Bgs]: mssql.textlimit and mssql.textsize can't be set via ini_set()
ID: 26791 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Bogus Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.3.4 New Comment: Sniper: Don't be so dismissive. Most ini_set()'s work just fine regardless of when they're called. Sessions aren't a good example because all of the session stuff has to be processed before any output. If the team doesn't want to spend time fixing this, please turn this into a documentation bug for ref.mssql.php, where a note should be made about the need to set these before connecting to a db. Previous Comments: [2004-01-08 23:21:09] [EMAIL PROTECTED] Of course the ini_set() has to be called before anything else is what might be using the setting. (this is the case for ANY setting, not just these mssql.* settings, see e.g. session stuff for examples) [2004-01-08 13:51:48] danielc at analysisandsolutions dot com Know what? The problem was where the ini_set() calls are made. They must be done BEFORE the connection is established. Once it's made, it can't be changed. Oddly, it doesn't matter when one calls ini_set() for mssql.datetimeconvert. So, I'm not sure this bug report should be closed, called bogus or not. It might be nice to have these work regardless of where they are called. If no change is made, the behavior needs to be documented. Couple things to keep in mind about my config: Using CGI Loading mssql via php.ini extensions Versions 4.3.4 and php5-win32-200401081130 snapshot [2004-01-08 00:12:28] [EMAIL PROTECTED] This seams to be related to how the extension is loaded. ini_set() works fine in php4 whn the extension is loaded from php.ini, but not when dl() is used. The dl() will also cause the output from phpinfo() to be incomplete! [2004-01-06 18:56:04] [EMAIL PROTECTED] Frank, nothing has changed in that function. Are you sure this really works with PHP 5..? [2004-01-05 02:44:12] [EMAIL PROTECTED] This works in PHP5 but not in PHP4.3.x (tested on the cvs version). Did something happen to the ini_set() funtion ? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/26791 -- Edit this bug report at http://bugs.php.net/?id=26791edit=1
#26799 [Fbk-Opn]: divide by zero errors not reported
ID: 26799
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Feedback
+Status: Open
Bug Type: MSSQL related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
Interesting. The query produces both a result and an error. I now see
that's how mssql intentionally operates.
By the way... mssql_min_error_severity() didn't change anything. But,
setting mssql_min_message_severity() to 0 caused a PHP warning on the
mssql_query() call.
Sample script:
--
$c = mssql_connect('localhost', 'sa', 'pw');
for ($Counter = 0; $Counter 17; $Counter++) {
//mssql_min_error_severity($Counter);
mssql_min_message_severity($Counter);
$result = mssql_query('SELECT 0/0 AS FOO', $c);
echo ' E: ' . mssql_get_last_message();
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
echo ' R: ' . gettype($ar['FOO']);
echo ' C: ' . $Counter;
echo 'br /';
}
Output:
---
Warning: mssql_query(): message: Division by zero occurred. (severity
0) in...
E: Division by zero occurred. R: NULL C: 0
... snipped similar output for brevity ...
E: Division by zero occurred. R: NULL C: 16
Previous Comments:
[2004-01-06 18:38:27] [EMAIL PROTECTED]
Try this script:
?php
error_reporting(E_ALL);
$c = mssql_connect('localhost', 'sa', 'pw');
$result = mssql_query('SELECT 0/0 AS FOO', $c);
echo mssql_get_last_message();
?
See also:
http://www.php.net/manual/en/function.mssql-min-error-severity.php
I think this is not really bug as is..the query doesn't actually
'fail'..
[2004-01-05 16:52:37] danielc at analysisandsolutions dot com
Exactly. That's why MSSQL considers it an error. But PHP doesn't
report back the error from MSSQL.
[2004-01-05 16:45:24] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Nonumber may be divided by zero.
[2004-01-05 16:31:25] danielc at analysisandsolutions dot com
Description:
MSSQL seems to not like queries that divide by zero -- see the OSQL
commands below. But, PHP doesn't report it as an error.
osql -Usa
1 SELECT 0/0 AS FOO
2 go
Msg 8134, Level 16, State 1, Server BASE2K, Line 1
Divide by zero error encountered.
Reproduce code:
---
$c = mssql_connect('localhost', 'sa', 'pw');
$result = @mssql_query('SELECT 0/0 AS FOO', $c);
if ($result) {
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
var_dump($ar);
} else {
echo mssql_get_last_message();
}
Expected result:
Divide by zero error encountered.
Actual result:
--
array(1) {
[foo]=
NULL
}
--
Edit this bug report at http://bugs.php.net/?id=26799edit=1
#26799 [Opn-Csd]: divide by zero errors not reported
ID: 26799
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Open
+Status: Closed
Bug Type: MSSQL related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
Close it.
Previous Comments:
[2004-01-06 23:27:16] danielc at analysisandsolutions dot com
Interesting. The query produces both a result and an error. I now see
that's how mssql intentionally operates.
By the way... mssql_min_error_severity() didn't change anything. But,
setting mssql_min_message_severity() to 0 caused a PHP warning on the
mssql_query() call.
Sample script:
--
$c = mssql_connect('localhost', 'sa', 'pw');
for ($Counter = 0; $Counter 17; $Counter++) {
//mssql_min_error_severity($Counter);
mssql_min_message_severity($Counter);
$result = mssql_query('SELECT 0/0 AS FOO', $c);
echo ' E: ' . mssql_get_last_message();
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
echo ' R: ' . gettype($ar['FOO']);
echo ' C: ' . $Counter;
echo 'br /';
}
Output:
---
Warning: mssql_query(): message: Division by zero occurred. (severity
0) in...
E: Division by zero occurred. R: NULL C: 0
... snipped similar output for brevity ...
E: Division by zero occurred. R: NULL C: 16
[2004-01-06 18:38:27] [EMAIL PROTECTED]
Try this script:
?php
error_reporting(E_ALL);
$c = mssql_connect('localhost', 'sa', 'pw');
$result = mssql_query('SELECT 0/0 AS FOO', $c);
echo mssql_get_last_message();
?
See also:
http://www.php.net/manual/en/function.mssql-min-error-severity.php
I think this is not really bug as is..the query doesn't actually
'fail'..
[2004-01-05 16:52:37] danielc at analysisandsolutions dot com
Exactly. That's why MSSQL considers it an error. But PHP doesn't
report back the error from MSSQL.
[2004-01-05 16:45:24] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Nonumber may be divided by zero.
[2004-01-05 16:31:25] danielc at analysisandsolutions dot com
Description:
MSSQL seems to not like queries that divide by zero -- see the OSQL
commands below. But, PHP doesn't report it as an error.
osql -Usa
1 SELECT 0/0 AS FOO
2 go
Msg 8134, Level 16, State 1, Server BASE2K, Line 1
Divide by zero error encountered.
Reproduce code:
---
$c = mssql_connect('localhost', 'sa', 'pw');
$result = @mssql_query('SELECT 0/0 AS FOO', $c);
if ($result) {
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
var_dump($ar);
} else {
echo mssql_get_last_message();
}
Expected result:
Divide by zero error encountered.
Actual result:
--
array(1) {
[foo]=
NULL
}
--
Edit this bug report at http://bugs.php.net/?id=26799edit=1
#26206 [NoF-Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: No Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: Sorry I didn't reply sooner. Situation still exists as of 500rc1-dev--php5-win32-200401022330. I still working on getting the build environment to function properly so I can determine when the change happened. Previous Comments: [2004-01-06 20:53:16] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2004-01-01 21:08:24] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2003-12-02 00:31:23] danielc at analysisandsolutions dot com Yes. Works fine with php4-win32-STABLE-200312020130.zip Are the old PHP5 snapshots available anywhere? I'll be glad to track down when this problem started. [2003-12-02 00:12:38] [EMAIL PROTECTED] Does PHP 4 snapshots work? [2003-12-01 13:57:39] danielc at analysisandsolutions dot com Everything worked fine until I switched from php5-win32-200310010230.zip to php5-win32-200311040330.zip I will track down exactly which snapshot in this time period started causing the problem. Then someone can examine the changes made in order to isolate the problem. Please inform me where I can find old snapshots to do this. http://snaps.php.net/win32/ only has the most recent few. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/26206 -- Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26799 [NEW]: divide by zero errors not reported
From: danielc at analysisandsolutions dot com
Operating system: Windows 2000
PHP version: 4.3.4
PHP Bug Type: MSSQL related
Bug description: divide by zero errors not reported
Description:
MSSQL seems to not like queries that divide by zero -- see the OSQL
commands below. But, PHP doesn't report it as an error.
osql -Usa
1 SELECT 0/0 AS FOO
2 go
Msg 8134, Level 16, State 1, Server BASE2K, Line 1
Divide by zero error encountered.
Reproduce code:
---
$c = mssql_connect('localhost', 'sa', 'pw');
$result = @mssql_query('SELECT 0/0 AS FOO', $c);
if ($result) {
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
var_dump($ar);
} else {
echo mssql_get_last_message();
}
Expected result:
Divide by zero error encountered.
Actual result:
--
array(1) {
[foo]=
NULL
}
--
Edit bug report at http://bugs.php.net/?id=26799edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26799r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26799r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26799r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26799r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26799r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26799r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26799r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26799r=support
Expected behavior: http://bugs.php.net/fix.php?id=26799r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26799r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26799r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26799r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26799r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26799r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26799r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26799r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26799r=float
#26799 [Bgs-Opn]: divide by zero errors not reported
ID: 26799
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Bogus
+Status: Open
Bug Type: MSSQL related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
Exactly. That's why MSSQL considers it an error. But PHP doesn't
report back the error from MSSQL.
Previous Comments:
[2004-01-05 16:45:24] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Nonumber may be divided by zero.
[2004-01-05 16:31:25] danielc at analysisandsolutions dot com
Description:
MSSQL seems to not like queries that divide by zero -- see the OSQL
commands below. But, PHP doesn't report it as an error.
osql -Usa
1 SELECT 0/0 AS FOO
2 go
Msg 8134, Level 16, State 1, Server BASE2K, Line 1
Divide by zero error encountered.
Reproduce code:
---
$c = mssql_connect('localhost', 'sa', 'pw');
$result = @mssql_query('SELECT 0/0 AS FOO', $c);
if ($result) {
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
var_dump($ar);
} else {
echo mssql_get_last_message();
}
Expected result:
Divide by zero error encountered.
Actual result:
--
array(1) {
[foo]=
NULL
}
--
Edit this bug report at http://bugs.php.net/?id=26799edit=1
#26791 [NEW]: mssql.textlimit and mssql.textsize can't be set via ini_set()
From: danielc at analysisandsolutions dot com
Operating system: Windows 2000
PHP version: 4.3.4
PHP Bug Type: MSSQL related
Bug description: mssql.textlimit and mssql.textsize can't be set via ini_set()
Description:
The mssql.textlimit and mssql.textsize configuration options
can't be set via ini_set(). Changing them in php.ini works.
This is also the case in a recent PHP 5 snapshot
(500rc1-dev--php5-win32-200401022330).
This is the same issue as bug 20797 which was closed due to no feedback.
SCRIPT CAN CHANGE LIMIT
===
php.ini
mssql.textlimit = 2147483647
mssql.textsize = 2147483647
script
SET TEXTSIZE 20
SCRIPT CAN'T CHANGE LIMIT
=
php.ini
mssql.textlimit = 20
mssql.textsize = 20
script
ini_set('mssql.textlimit', 2147483647);
ini_set('mssql.textsize', 2147483647);
php.ini
mssql.textlimit = 2147483647
mssql.textsize = 2147483647
script
ini_set('mssql.textlimit', 20);
ini_set('mssql.textsize', 20);
php.ini
; mssql.textlimit = 2147483647
; mssql.textsize = 2147483647
script
SET TEXTSIZE 2147483647
php.ini
mssql.textlimit = 20
mssql.textsize = 20
script
SET TEXTSIZE 2147483647
--
Edit bug report at http://bugs.php.net/?id=26791edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26791r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26791r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26791r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26791r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26791r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26791r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26791r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26791r=support
Expected behavior: http://bugs.php.net/fix.php?id=26791r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26791r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26791r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26791r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26791r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26791r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26791r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26791r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26791r=float
#20797 [Com]: 4k text limitation can be adjusted by INI_SET
ID: 20797 Comment by: danielc at analysisandsolutions dot com Reported By: carl dot landry at emergis dot com Status: No Feedback Bug Type: MSSQL related Operating System: Windows NT 4.0 build 1381 PHP Version: 4.2.2 New Comment: This is still an issue. Opened new bug: http://bugs.php.net/bug.php?id=26791 Previous Comments: [2003-01-02 18:41:35] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2002-12-07 01:20:46] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-03 13:05:28] carl dot landry at emergis dot com To adjust the 4k limitation of TEXT fields, I changed the TEXTSIZE and TEXTLIMIT value of MSSQL (SET TEXTSIZE xxx) to a very high value to prevent interference. This works properly. Adjusting the mssql.textlimit and mssql.textsize values in php.ini would allow larger than 4k results to be returned. This seems also fine. However, changing this limit at run time (ini_set(mssql.textlimit, 12000); ini_set(mssql.textsize, 12000);, 12000 (int) or 12000 string, not making a difference) would have no impact on the selected result. PHPINFO() shows the new adjusted value but the result would still be limited to the value set in the PHP.INI file. Also, -1 (as suggested in the INI_SET function description page) seems to limit to 4k too. Server API: ISAPI MSSQL Library version: 7.0 More information can be supplied if requested. -- Edit this bug report at http://bugs.php.net/?id=20797edit=1
#26418 [Fbk-Csd]: loading class files crashes
ID: 26418
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Feedback
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Windows 2000
PHP Version: 5CVS-2003-12-1
New Comment:
Works fine so far. Thanks.
Previous Comments:
[2003-12-15 09:48:01] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Can not reproduce..
[2003-12-01 13:41:57] danielc at analysisandsolutions dot com
#! c:/progra~1/php/cli/php
?php
/*
* http://bugs.php.net/bug.php?id=26418
*
* Notice the inclusion of PEAR's DB class at the bottom. Make sure
* your include_path or the path in the require statement below is
* correct.
*
* The crashes involve a weird combination of factors. The factors
* can be rearranged to cause the crashes to vanish.
*
* If the parent class' name is 15 characters long, it crashes, but if
* it's 14 or 16 characters long, it does not. But the length of the
* class name isn't _really_ the problem.
*
* For example, the length of the method names and the existence of
* parameters play a role too. See the comment in the class for more
* details.
*/
//class A2345678901234 {
class A23456789012345 {
//class A234567890123456 {
}
//class B extends A2345678901234 {
class B extends A23456789012345 {
//class B extends A234567890123456 {
function foo() {}
function goo($Directory) {}
/*
* Crashes if the next method name is = 21 characters long.
* But doesn't crash if both methods are uncommented.
* Similarly, doesn't crash if the parameter, $Directory, is
removed
* from method goo(), above.
*/
function a2345689012345678901() {}
//function a23456890123456789012() {}
}
require_once('DB.php');
?
[2003-11-26 02:24:47] danielc at analysisandsolutions dot com
Description:
Using the latest snapshot, php5-win32-200311260330.zip, when a script
loads up a bunch of class files, a Dr Watson error dialog appears
saying PHP has crashed. Note, I'm just including the files, not
creating an object via new.
I've tried to pin this down to some particular lines of code, but have
been unable to find something in particular.
While certain combinations of my class files and PEAR::DB create the
crash, others don't.
This code worked fine until now, so I don't think it's the content. In
addition, I've tweaked PEAR.php and DB.php so methods that return by
reference are always returning variables.
Below is an excerpt from a dump file as examined by WinDbg:
(5e4.600): Access violation - code c005 (!!! second chance !!!)
eax=00866dfc ebx=00d9ad80 ecx=6e692e67 edx=0063 esi=00d9c5e0
edi=00d9c658
eip=100dcf91 esp=0012fae8 ebp=78001db0 iopl=0 nv up ei pl nz na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=
efl=0202
*** WARNING: Unable to verify checksum for php4ts.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols
for php4ts.dll -
php4ts!zend_ts_hash_rehash+481:
100dcf91 89510c mov [ecx+0xc],edx
ds:0023:6e692e73=
--
Edit this bug report at http://bugs.php.net/?id=26418edit=1
#26206 [Fbk-Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: 100% certain. New PHP installs on this system are by moving the entirety of the old install aside, extracting the contents of a new snapshot .zip file then copying the exact files/structure over to the php directory. The system finds the DLLS via the %path%, in which C:\PROGRA~1\Php;C:\PROGRA~1\Php\dlls; are the first two entries. The PHP DLL's have never been copied to any other location on this computer. Previous Comments: [2003-12-01 03:25:23] [EMAIL PROTECTED] And you're absolutely sure you don't have ANY old PHP related dlls in your system before you installed the snapshot? (delete all php4ts.dll files..) [2003-12-01 00:35:22] danielc at analysisandsolutions dot com No luck with the new snapshot. Downloaded php5-win32-200312010330.zip, copied php.ini-recommended to php.ini, turned register_argc_argv = On, ran the following... C:\PROGRA~1\php\cliphp -i | grep argv register_argc_argv = On = On C:\PROGRA~1\php\cliphp -r var_dump($_SERVER['argv']); 1 2 3 PHP Notice: Undefined index: argv in Command line code on line 1 NULL [2003-11-29 00:15:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I can not reproduce this on windows using latest CVS snapshot. [2003-11-27 19:24:09] danielc at analysisandsolutions dot com Your test of ignoring the php.ini file via the -n flag gets it to work as expected. FYI... C:\PROGRA~1\php\cliphp -i | grep argv register_argc_argv = On = On C:\PROGRA~1\php\cliphp -n -i | grep argv register_argc_argv = On = On _SERVER[argv] = Array C:\PROGRA~1\php\cliphp -v PHP 5.0.0b3-dev (cli) (built: Nov 26 2003 04:10:19) [2003-11-27 19:03:46] [EMAIL PROTECTED] Try following: php -n -r var_dump($_SERVER['argv']); 1 2 3 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/26206 -- Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26418 [Fbk-Opn]: loading class files crashes
ID: 26418
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Feedback
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Windows 2000
PHP Version: 5CVS-2003-12-1
New Comment:
#! c:/progra~1/php/cli/php
?php
/*
* http://bugs.php.net/bug.php?id=26418
*
* Notice the inclusion of PEAR's DB class at the bottom. Make sure
* your include_path or the path in the require statement below is
* correct.
*
* The crashes involve a weird combination of factors. The factors
* can be rearranged to cause the crashes to vanish.
*
* If the parent class' name is 15 characters long, it crashes, but if
* it's 14 or 16 characters long, it does not. But the length of the
* class name isn't _really_ the problem.
*
* For example, the length of the method names and the existence of
* parameters play a role too. See the comment in the class for more
* details.
*/
//class A2345678901234 {
class A23456789012345 {
//class A234567890123456 {
}
//class B extends A2345678901234 {
class B extends A23456789012345 {
//class B extends A234567890123456 {
function foo() {}
function goo($Directory) {}
/*
* Crashes if the next method name is = 21 characters long.
* But doesn't crash if both methods are uncommented.
* Similarly, doesn't crash if the parameter, $Directory, is
removed
* from method goo(), above.
*/
function a2345689012345678901() {}
//function a23456890123456789012() {}
}
require_once('DB.php');
?
Previous Comments:
[2003-12-01 03:22:51] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
[2003-12-01 00:39:30] danielc at analysisandsolutions dot com
Same problem with new snapshot: php5-win32-200312010330.zip
[2003-11-28 23:48:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2003-11-26 02:24:47] danielc at analysisandsolutions dot com
Description:
Using the latest snapshot, php5-win32-200311260330.zip, when a script
loads up a bunch of class files, a Dr Watson error dialog appears
saying PHP has crashed. Note, I'm just including the files, not
creating an object via new.
I've tried to pin this down to some particular lines of code, but have
been unable to find something in particular.
While certain combinations of my class files and PEAR::DB create the
crash, others don't.
This code worked fine until now, so I don't think it's the content. In
addition, I've tweaked PEAR.php and DB.php so methods that return by
reference are always returning variables.
Below is an excerpt from a dump file as examined by WinDbg:
(5e4.600): Access violation - code c005 (!!! second chance !!!)
eax=00866dfc ebx=00d9ad80 ecx=6e692e67 edx=0063 esi=00d9c5e0
edi=00d9c658
eip=100dcf91 esp=0012fae8 ebp=78001db0 iopl=0 nv up ei pl nz na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=
efl=0202
*** WARNING: Unable to verify checksum for php4ts.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols
for php4ts.dll -
php4ts!zend_ts_hash_rehash+481:
100dcf91 89510c mov [ecx+0xc],edx
ds:0023:6e692e73=
--
Edit this bug report at http://bugs.php.net/?id=26418edit=1
#26206 [Bgs-Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Bogus +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: Everything worked fine until I switched from php5-win32-200310010230.zip to php5-win32-200311040330.zip I will track down exactly which snapshot in this time period started causing the problem. Then someone can examine the changes made in order to isolate the problem. Please inform me where I can find old snapshots to do this. http://snaps.php.net/win32/ only has the most recent few. Previous Comments: [2003-12-01 13:31:20] [EMAIL PROTECTED] Well, I can't reproduce this with either CLI or CGI, using either php.ini-dist or php.ini-recommended. So there's something wrong with your system, not PHP. [2003-12-01 12:04:35] danielc at analysisandsolutions dot com 100% certain. New PHP installs on this system are by moving the entirety of the old install aside, extracting the contents of a new snapshot .zip file then copying the exact files/structure over to the php directory. The system finds the DLLS via the %path%, in which C:\PROGRA~1\Php;C:\PROGRA~1\Php\dlls; are the first two entries. The PHP DLL's have never been copied to any other location on this computer. [2003-12-01 03:25:23] [EMAIL PROTECTED] And you're absolutely sure you don't have ANY old PHP related dlls in your system before you installed the snapshot? (delete all php4ts.dll files..) [2003-12-01 00:35:22] danielc at analysisandsolutions dot com No luck with the new snapshot. Downloaded php5-win32-200312010330.zip, copied php.ini-recommended to php.ini, turned register_argc_argv = On, ran the following... C:\PROGRA~1\php\cliphp -i | grep argv register_argc_argv = On = On C:\PROGRA~1\php\cliphp -r var_dump($_SERVER['argv']); 1 2 3 PHP Notice: Undefined index: argv in Command line code on line 1 NULL [2003-11-29 00:15:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I can not reproduce this on windows using latest CVS snapshot. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/26206 -- Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26206 [Fbk-Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: Yes. Works fine with php4-win32-STABLE-200312020130.zip Are the old PHP5 snapshots available anywhere? I'll be glad to track down when this problem started. Previous Comments: [2003-12-02 00:12:38] [EMAIL PROTECTED] Does PHP 4 snapshots work? [2003-12-01 13:57:39] danielc at analysisandsolutions dot com Everything worked fine until I switched from php5-win32-200310010230.zip to php5-win32-200311040330.zip I will track down exactly which snapshot in this time period started causing the problem. Then someone can examine the changes made in order to isolate the problem. Please inform me where I can find old snapshots to do this. http://snaps.php.net/win32/ only has the most recent few. [2003-12-01 13:31:20] [EMAIL PROTECTED] Well, I can't reproduce this with either CLI or CGI, using either php.ini-dist or php.ini-recommended. So there's something wrong with your system, not PHP. [2003-12-01 12:04:35] danielc at analysisandsolutions dot com 100% certain. New PHP installs on this system are by moving the entirety of the old install aside, extracting the contents of a new snapshot .zip file then copying the exact files/structure over to the php directory. The system finds the DLLS via the %path%, in which C:\PROGRA~1\Php;C:\PROGRA~1\Php\dlls; are the first two entries. The PHP DLL's have never been copied to any other location on this computer. [2003-12-01 03:25:23] [EMAIL PROTECTED] And you're absolutely sure you don't have ANY old PHP related dlls in your system before you installed the snapshot? (delete all php4ts.dll files..) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/26206 -- Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26206 [Fbk-Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: No luck with the new snapshot. Downloaded php5-win32-200312010330.zip, copied php.ini-recommended to php.ini, turned register_argc_argv = On, ran the following... C:\PROGRA~1\php\cliphp -i | grep argv register_argc_argv = On = On C:\PROGRA~1\php\cliphp -r var_dump($_SERVER['argv']); 1 2 3 PHP Notice: Undefined index: argv in Command line code on line 1 NULL Previous Comments: [2003-11-29 00:15:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I can not reproduce this on windows using latest CVS snapshot. [2003-11-27 19:24:09] danielc at analysisandsolutions dot com Your test of ignoring the php.ini file via the -n flag gets it to work as expected. FYI... C:\PROGRA~1\php\cliphp -i | grep argv register_argc_argv = On = On C:\PROGRA~1\php\cliphp -n -i | grep argv register_argc_argv = On = On _SERVER[argv] = Array C:\PROGRA~1\php\cliphp -v PHP 5.0.0b3-dev (cli) (built: Nov 26 2003 04:10:19) [2003-11-27 19:03:46] [EMAIL PROTECTED] Try following: php -n -r var_dump($_SERVER['argv']); 1 2 3 [2003-11-11 12:52:32] danielc at analysisandsolutions dot com Description: $_SERVER['argv'] and $_SERVER['argc'] aren't created. php.ini and phpinfo() show register_argc_argv as being On. Behavior is the same via CLI or CGI binaries. Substituted a known good php.ini file to see ensure the file was getting parsed. Same results. Everything worked fine under 500b2-dev--php5-win32-200310010230 Problem began when upgraded to 500b2-dev--php5-win32-200311040330 Persists in the current CVS snapshot 500b3-dev--php5-win32-20031530 Reproduce code: --- #! c:/progra~1/php/cli/php ?php print_r($_SERVER['argv']); ? now execute test script... ./t.php fjiao Expected result: Array ( [0] = ./t.php [1] = fjiao ) Actual result: -- Notice: Undefined index: argv in d:\t.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26418 [Fbk-Opn]: loading class files crashes
ID: 26418 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: Windows 2000 PHP Version: 5CVS-2003-11-26 (dev) New Comment: Same problem with new snapshot: php5-win32-200312010330.zip Previous Comments: [2003-11-28 23:48:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2003-11-26 02:24:47] danielc at analysisandsolutions dot com Description: Using the latest snapshot, php5-win32-200311260330.zip, when a script loads up a bunch of class files, a Dr Watson error dialog appears saying PHP has crashed. Note, I'm just including the files, not creating an object via new. I've tried to pin this down to some particular lines of code, but have been unable to find something in particular. While certain combinations of my class files and PEAR::DB create the crash, others don't. This code worked fine until now, so I don't think it's the content. In addition, I've tweaked PEAR.php and DB.php so methods that return by reference are always returning variables. Below is an excerpt from a dump file as examined by WinDbg: (5e4.600): Access violation - code c005 (!!! second chance !!!) eax=00866dfc ebx=00d9ad80 ecx=6e692e67 edx=0063 esi=00d9c5e0 edi=00d9c658 eip=100dcf91 esp=0012fae8 ebp=78001db0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs= efl=0202 *** WARNING: Unable to verify checksum for php4ts.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for php4ts.dll - php4ts!zend_ts_hash_rehash+481: 100dcf91 89510c mov [ecx+0xc],edx ds:0023:6e692e73= -- Edit this bug report at http://bugs.php.net/?id=26418edit=1
#26206 [Fbk-Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: Your test of ignoring the php.ini file via the -n flag gets it to work as expected. FYI... C:\PROGRA~1\php\cliphp -i | grep argv register_argc_argv = On = On C:\PROGRA~1\php\cliphp -n -i | grep argv register_argc_argv = On = On _SERVER[argv] = Array C:\PROGRA~1\php\cliphp -v PHP 5.0.0b3-dev (cli) (built: Nov 26 2003 04:10:19) Previous Comments: [2003-11-27 19:03:46] [EMAIL PROTECTED] Try following: php -n -r var_dump($_SERVER['argv']); 1 2 3 [2003-11-11 12:52:32] danielc at analysisandsolutions dot com Description: $_SERVER['argv'] and $_SERVER['argc'] aren't created. php.ini and phpinfo() show register_argc_argv as being On. Behavior is the same via CLI or CGI binaries. Substituted a known good php.ini file to see ensure the file was getting parsed. Same results. Everything worked fine under 500b2-dev--php5-win32-200310010230 Problem began when upgraded to 500b2-dev--php5-win32-200311040330 Persists in the current CVS snapshot 500b3-dev--php5-win32-20031530 Reproduce code: --- #! c:/progra~1/php/cli/php ?php print_r($_SERVER['argv']); ? now execute test script... ./t.php fjiao Expected result: Array ( [0] = ./t.php [1] = fjiao ) Actual result: -- Notice: Undefined index: argv in d:\t.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26418 [NEW]: loading class files crashes
From: danielc at analysisandsolutions dot com Operating system: Windows 2000 PHP version: 5CVS-2003-11-26 (dev) PHP Bug Type: Reproducible crash Bug description: loading class files crashes Description: Using the latest snapshot, php5-win32-200311260330.zip, when a script loads up a bunch of class files, a Dr Watson error dialog appears saying PHP has crashed. Note, I'm just including the files, not creating an object via new. I've tried to pin this down to some particular lines of code, but have been unable to find something in particular. While certain combinations of my class files and PEAR::DB create the crash, others don't. This code worked fine until now, so I don't think it's the content. In addition, I've tweaked PEAR.php and DB.php so methods that return by reference are always returning variables. Below is an excerpt from a dump file as examined by WinDbg: (5e4.600): Access violation - code c005 (!!! second chance !!!) eax=00866dfc ebx=00d9ad80 ecx=6e692e67 edx=0063 esi=00d9c5e0 edi=00d9c658 eip=100dcf91 esp=0012fae8 ebp=78001db0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs= efl=0202 *** WARNING: Unable to verify checksum for php4ts.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for php4ts.dll - php4ts!zend_ts_hash_rehash+481: 100dcf91 89510c mov [ecx+0xc],edx ds:0023:6e692e73= -- Edit bug report at http://bugs.php.net/?id=26418edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26418r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26418r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26418r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26418r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26418r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26418r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26418r=support Expected behavior: http://bugs.php.net/fix.php?id=26418r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26418r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26418r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26418r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26418r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26418r=dst IIS Stability: http://bugs.php.net/fix.php?id=26418r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26418r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26418r=float
#26206 [NEW]: argv and argc not defined
From: danielc at analysisandsolutions dot com Operating system: Windows 2000 PHP version: 5CVS-2003-11-11 (dev) PHP Bug Type: Unknown/Other Function Bug description: argv and argc not defined Description: $_SERVER['argv'] and $_SERVER['argc'] aren't created. php.ini and phpinfo() show register_argc_argv as being On. Behavior is the same via CLI or CGI binaries. Substituted a known good php.ini file to see ensure the file was getting parsed. Same results. Everything worked fine under 500b2-dev--php5-win32-200310010230 Problem began when upgraded to 500b2-dev--php5-win32-200311040330 Persists in the current CVS snapshot 500b3-dev--php5-win32-20031530 Reproduce code: --- #! c:/progra~1/php/cli/php ?php print_r($_SERVER['argv']); ? now execute test script... ./t.php fjiao Expected result: Array ( [0] = ./t.php [1] = fjiao ) Actual result: -- Notice: Undefined index: argv in d:\t.php on line 3 -- Edit bug report at http://bugs.php.net/?id=26206edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26206r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26206r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26206r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26206r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26206r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26206r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26206r=support Expected behavior: http://bugs.php.net/fix.php?id=26206r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26206r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26206r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26206r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26206r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26206r=dst IIS Stability: http://bugs.php.net/fix.php?id=26206r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26206r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26206r=float
#26207 [NEW]: date(): add format parameter for colons in UTC offset
From: danielc at analysisandsolutions dot com
Operating system: irrelevant
PHP version: Irrelevant
PHP Bug Type: Feature/Change Request
Bug description: date(): add format parameter for colons in UTC offset
Description:
date('O') produces the offset in +0200 format. It would be nice to be
able to have a format parameter that
outputs the same information but with a colon in it: +02:00.
--
Edit bug report at http://bugs.php.net/?id=26207edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26207r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26207r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26207r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26207r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26207r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26207r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26207r=support
Expected behavior: http://bugs.php.net/fix.php?id=26207r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26207r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26207r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26207r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26207r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26207r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26207r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26207r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26207r=float
#23467 [Com]: Showing incorrect Time Zone
ID: 23467
Comment by: danielc at analysisandsolutions dot com
Reported By: John at JGSystems dot net
Status: Verified
Bug Type: Date/time related
Operating System: win32
PHP Version: 4.3.4-dev, 5.0.0b2-dev
New Comment:
Um, sorry if I'm cluttering the list... This bug is half a year old so
I'm wondering if/when it's going to get fixed.
Y'all probably know what's going on, but allow me to clarify what I've
learned about this bug, perhaps it will help someone.
date('T') doesn't work under Windows during Daylight times and there's
no notation of this in the manual. I'll put a user comment in there.
Here's a test script:
?php
echo 'Local: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo \nbr /;
putenv('TZ=EST5EDT');
echo 'EST5EDT: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo \nbr /;
putenv('TZ=PST8PDT');
echo 'PST8PDT: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo \nbr /;
putenv('TZ=GMT0BST');
echo 'GMT0BST: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo \nbr /;
putenv('TZ=MST-3MDT');
echo 'MST-3MDT: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo \nbr /;
putenv('TZ=GMT');
echo 'GMT: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
?
OUTPUT DURING EASTERN DAYLIGHT TIME
---
Local: dT=BST dO=-0400 sZ=Eastern Daylight Time
EST5EDT: dT=BST dO=-0400 sZ=EDT
PST8PDT: dT=BST dO=-0700 sZ=PDT
GMT0BST: dT=BST dO=+0100 sZ=BST
MST-3MDT: dT=BST dO=+0400 sZ=MDT
GMT: dT=GMT dO=+ sZ=GMT
OUTPUT DURING EASTERN STANDARD TIME
---
Local: dT=Eastern Standard Time dO=-0500 sZ=Eastern Standard Time
EST5EDT: dT=EST dO=-0500 sZ=EST
PST8PDT: dT=PST dO=-0800 sZ=PST
GMT0BST: dT=GMT dO=+ sZ=GMT
MST-3MDT: dT=MST dO=+0300 sZ=MST
GMT: dT=GMT dO=+ sZ=GMT
Previous Comments:
[2003-08-26 22:59:32] [EMAIL PROTECTED]
This is general win32 problem. No need to post anymore comments here,
we know about it.
[2003-08-20 20:35:39] John at JGSystems dot net
Here ya go:
Commands:
echo date(r),br\n;
echo date(I),br\n; // uppercase i
echo date(T),br\n;
Result:
Wed, 20 Aug 2003 19:33:34 -0600
1
BST
This what you wanted? (I hope)
[2003-08-19 23:12:26] John at JGSystems dot net
The time last modified was pasted in the reply.
This page was last modified:
Monday - May 19, 2003 at 4:22 PM BST.
I'll get the current time pasted in tomorrow...
The results of:
echo date(r),\n;
echo date(I),\n; // uppercase i
Too late tonight...
[2003-08-19 22:48:30] [EMAIL PROTECTED]
I wanted to know the TIME...not the time zone..
[2003-08-19 21:12:06] John at JGSystems dot net
It's a local machine. Win XP. Nothings changed from the items listed
below in this thread or I would have mentioned it.
I downloaded the link, installed it after erasing the last version you
all had me try and the same result. I did tell you that it was
supposed to be -- MDT -- not -- BST --
Thanks...
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/23467
--
Edit this bug report at http://bugs.php.net/?id=23467edit=1
#26090 [NEW]: allow colons in time zone offset to strtotime()
From: danielc at analysisandsolutions dot com
Operating system: n/a
PHP version: 5.0.0b1 (beta1)
PHP Bug Type: Feature/Change Request
Bug description: allow colons in time zone offset to strtotime()
Description:
The strtotime() function doesn't allow time zone offsets to contain colons
: in them. Colons are included in several offset formmating standards.
Reproduce code:
---
$t = '2003-10-28 10:20:30-0800';
echo date('Y-m-d H:i:s T', strtotime($t)) . \nbr /\n;
$t = '2003-10-28 10:20:30-08:00';
echo date('Y-m-d H:i:s T', strtotime($t)) . \n;
Expected result:
2003-10-28 13:20:30 EST
br /
2003-10-28 13:20:30 EST
Actual result:
--
2003-10-28 13:20:30 EST
br /
1969-12-31 18:59:59 EST
On Windows 2000, the attempt with the colons in the offset produces a
negative timestamp, so the beloved Windows does not support dates prior
to midnight warning arises.
--
Edit bug report at http://bugs.php.net/?id=26090edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26090r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26090r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26090r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26090r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26090r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26090r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26090r=support
Expected behavior: http://bugs.php.net/fix.php?id=26090r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26090r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26090r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26090r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26090r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26090r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26090r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26090r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26090r=float
#25826 [NEW]: undefined notices via unset()
From: danielc at analysisandsolutions dot com
Operating system: Windows 2000
PHP version: Irrelevant
PHP Bug Type: Zend Engine 2 problem
Bug description: undefined notices via unset()
Description:
unset() acts inconsistently when acting upon array keys that don't exist.
In some cases it throws Notices about Undefined index Undefined
variable and Undefined property.
The behavior varies depending on
a) the dimension of the array trying to be unset
b) whether the array is set
c) if the unset() call is in a class
d) the version of PHP being used
Reproduce code:
---
?php
class test {
var $Array2 = array();
function test() {
unset($this-Nada); // no problem
unset($this-Array1['one:one']);// 4.3.3: Undefined property
// 500b2: no problem
unset($this-Array1['one:two'][1]); // 4.3.3: Undefined property
// 500b2: no problem
unset($this-Array2['two:one']);// no problem
unset($this-Array2['two:two'][1]); // Undefined index
unset($Nada); // no problem
unset($Array3['three:one']);// Undefined variable
unset($Array3['three:two'][1]); // Undefined variable
$Array4 = array();
unset($Array4['four:one']); // no problem
unset($Array4['four:two'][1]); // Undefined index
}
}
$test1 = new test();
unset($Nada); // no problem
unset($Array5['five:one']); // Undefined variable
unset($Array5['five:two'][1]); // Undefined variable
$Array6 = array();
unset($Array6['six:one']); // no problem
unset($Array6['six:two'][1]); // Undefined index
?
Expected result:
No notices at all.
Considering no notice was produced on a non-existant scalar, I expected
the same behavior when trying to unset various arrays, regardless of where
the unset() all is made.
Actual result:
--
PHP 4.3.3
Notice: Undefined property: Array1 in t.php on line 12
Notice: Undefined property: Array1 in t.php on line 13
Notice: Undefined index: two:two in t.php on line 16
Notice: Undefined variable: Array3 in t.php on line 20
Notice: Undefined variable: Array3 in t.php on line 21
Notice: Undefined index: four:two in t.php on line 25
Notice: Undefined variable: Array5 in t.php on line 33
Notice: Undefined variable: Array5 in t.php on line 34
Notice: Undefined index: six:two in t.php on line 38
PHP 500b2-dev 200310010230
Notice: Undefined index: two:two in t.php on line 16
Notice: Undefined variable: Array3 in t.php on line 20
Notice: Undefined variable: Array3 in t.php on line 21
Notice: Undefined index: four:two in t.php on line 25
Notice: Undefined variable: Array5 in t.php on line 33
Notice: Undefined variable: Array5 in t.php on line 34
Notice: Undefined index: six:two in t.php on line 38
--
Edit bug report at http://bugs.php.net/?id=25826edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25826r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25826r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25826r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25826r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25826r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25826r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25826r=support
Expected behavior: http://bugs.php.net/fix.php?id=25826r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25826r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25826r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25826r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25826r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25826r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25826r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25826r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=25826r=float
#24960 [NEW]: php_domxml.dll in php.ini but not in extensions dir
From: danielc at analysisandsolutions dot com Operating system: Windows PHP version: 5.0.0b1 (beta1) PHP Bug Type: *Configuration Issues Bug description: php_domxml.dll in php.ini but not in extensions dir Description: php_domxml.dll is in the php.ini file but is not in the extensions directory. Please either remove the reference to it from php.ini or add the DLL to the extensions directory. -- Edit bug report at http://bugs.php.net/?id=24960edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24960r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24960r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24960r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24960r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24960r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24960r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24960r=support Expected behavior: http://bugs.php.net/fix.php?id=24960r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24960r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24960r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24960r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24960r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24960r=dst IIS Stability: http://bugs.php.net/fix.php?id=24960r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24960r=gnused
#24969 [NEW]: multiple DLLs listed in php.ini but not in extensions dir
From: danielc at analysisandsolutions dot com Operating system: Windows PHP version: 5CVS-2003-08-07 (dev) PHP Bug Type: *Configuration Issues Bug description: multiple DLLs listed in php.ini but not in extensions dir Description: In the php5-win32-200308070230.zip snapshot... The php.ini file has several DLLs listed in the Windows Extensions section even though the DLLs in question don't exist in the extensions directory: php_curl.dll php_filepro.dll php_hyperwave.dll php_iisfunc.dll php_java.dll php_ldap.dll php_mbstring.dll php_mssql.dll php_oci8.dll php_openssl.dll php_oracle.dll php_pgsql.dll php_printer.dll php_sockets.dll php_w32api.dll php_xmlrpc.dll php_yaz.dll php_zip.dll -- Edit bug report at http://bugs.php.net/?id=24969edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24969r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24969r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24969r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24969r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24969r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24969r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24969r=support Expected behavior: http://bugs.php.net/fix.php?id=24969r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24969r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24969r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24969r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24969r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24969r=dst IIS Stability: http://bugs.php.net/fix.php?id=24969r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24969r=gnused
