#34003 [NEW]: bugreports feedback
From: de at nospam dot net Operating system: PHP version: 5.1.0b3 PHP Bug Type: *General Issues Bug description: bugreports feedback Description: I hope the targeted audience is reading this before removing it... I know you are busy doing things... but I think it would be nice to consider the reports a bit more carefully than just writing "this is not a bug"... like it was for example done in #33679 (but I saw it in a few other reports as well). But see #33558 ... if I am not completly wrong, there at least calling a function which returned a reference were eventually accepted to be a bug and fixed. (It does not tell anything about the other two versions though) Which means #33679 was not completly "Bogus". And if you were asking me as a developer (making use of some programming languages), what was in #33679 expected is general practise of OOP. And to me it seemed, that this is something PHP want to move toward. -- Edit bug report at http://bugs.php.net/?id=34003&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34003&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34003&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34003&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34003&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34003&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34003&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34003&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34003&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34003&r=support Expected behavior: http://bugs.php.net/fix.php?id=34003&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34003&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34003&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34003&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34003&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34003&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34003&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34003&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34003&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34003&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34003&r=mysqlcfg
#33994 [WFx]: DB unavailable after forked child exits
ID: 33994
User updated by: greatwhitepine at bigfoot dot com
Reported By: greatwhitepine at bigfoot dot com
Status: Wont fix
Bug Type: Ingres II related
Operating System: Tru64 UNIX V5.1B (Rev. 2650)
PHP Version: 5.0.4
New Comment:
The workaround is not required if the parent db connections are
properly closed before spawning children. Sorry about that Sniper.
Previous Comments:
[2005-08-05 00:15:23] greatwhitepine at bigfoot dot com
Just in case anyone might care I have a workaround... the parent must
not open a db connection until all children have completed. Thus if
the parent needs to use the db before forking child processes it should
fork a db_child process to do so.
This code works as expected...
print 'parent before parent query'."\n\n";
$int_pid = pcntl_fork();
if(!$int_pid) {
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from auto_ldg_run')) {
print 'db ok for for parent query'."\n\n";
}
exit();
}
pcntl_waitpid($int_pid, $int_returnCode, WUNTRACED);
print 'parent before child process is spawned'."\n\n";
$arr_pids = FALSE;
for ($i=0; $i < 3; $i++) {
$arr_pids[] = pcntl_fork();
if(!$arr_pids[$i]) {
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from auto_ldg_run')) {
print 'db ok for child '.$i." \n\n";
}
exit();
}
}
for ($i=0; $i < 3; $i++) {
pcntl_waitpid($arr_pids[$i], $int_returnCode, WUNTRACED);
}
print 'parent after children have completed'."\n\n";
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from auto_ldg_run')) {
print 'db ok for parent after children have completed'."\n\n";
}
Output...
parent before parent query
db ok for for parent query
parent before child process is spawned
db ok for child 0
db ok for child 1
db ok for child 2
parent after children have completed
db ok for parent after children have completed
[2005-08-04 18:39:52] greatwhitepine at bigfoot dot com
Seperate connections does not work (as per the example)!
[2005-08-04 08:45:38] [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
Use separate connections or something else than ingres (moved to PECL,
report bugs on it to pecl.php.net/bugs..)
[2005-08-04 08:14:13] greatwhitepine at bigfoot dot com
Sorry, forgot the pcntl_waitpid during my 1st edit (see below).
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from auto_ldg_run')) {
print 'db ok during fork'."\n\n";
}
$int_pid = pcntl_fork();
if(!$int_pid) {
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from auto_ldg_run')) {
print 'db ok for child'."\n\n";
}
exit();
}
pcntl_waitpid ($int_pid, $str_status);
ingres_connect($str_database, $str_username, $str_password);
if (!ingres_query('select count(*) from auto_ldg_run')) {
print 'db not ok after fork'."\n\n";
}
exit(1);
[2005-08-04 08:03:06] greatwhitepine at bigfoot dot com
Description:
As per the manual ingres_connect connections are terminated when the
process exits. When a forked child exits the connection is terminated
permanently until the parent process is restarted.
Reproduce code:
---
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from table')) {
print 'db ok during fork'."\n\n";
}
$int_pid = pcntl_fork();
if(!$int_pid) {
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from table')) {
print 'db ok for child'."\n\n";
}
exit();
}
ingres_connect($str_database, $str_username, $str_password);
if (!ingres_query('select count(*) from table')) {
print 'db not ok after fork'."\n\n";
}
Expected result:
db ok during fork
db ok for child
Actual result:
--
db ok during fork
db ok for child
Warning: ingres_query(): Ingres II: Server or API error : Read from
peer process failed; it may have exited. in
/home/its/autoldg/lib/php/local/lib_autoldg_daemon.php on line 228
Warning: ingres_query(): Ingres II: SQLSTATE : 08004 in
/home/its/autoldg/lib/php/local/lib_autoldg_daemon.php on line 228
db not ok after fork
Warning: Unknown: Ingres II: Server or API error : API function cannot
be called in the current state. in Unkno
#34002 [NEW]: Additional array creation construct
From: syncops at hotmail dot com
Operating system: All
PHP version: 5CVS-2005-08-05 (dev)
PHP Bug Type: Feature/Change Request
Bug description: Additional array creation construct
Description:
I use associative arrays for so many things like function/method
parameters, database records, creating URL's and HTML tags.
I'm looking at tons of array creation code in my application because the
only way to create an array is by using the array("key1"=>"value1",
"key2"=>"value2") construct.
The following construct would be a very good addition and is also used in
other (script)languages:
{"key1"=>"value1", "key2"=>"value2"}.
I sincerely hope there is some way to implemented this new construct.
Thanks for reading this.
--
Edit bug report at http://bugs.php.net/?id=34002&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34002&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34002&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34002&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34002&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34002&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34002&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34002&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34002&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34002&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34002&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34002&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34002&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34002&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34002&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34002&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34002&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34002&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34002&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34002&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34002&r=mysqlcfg
#34001 [NEW]: truncating value when optional display width value is used
From: james at safesearching dot com
Operating system: *
PHP version: 5.1.0b3
PHP Bug Type: PDO related
Bug description: truncating value when optional display width value is used
Description:
PDO seems to be trucating the value from MySQL when using the optional
display width syntax (ie, mediumint(4)).
>From http://dev.mysql.com/doc/mysql/en/numeric-types.html
...
The display width does not constrain the range of values that can be
stored in the column, nor the number of digits that are displayed for
values having a width exceeding that specified for the column.
I'm not sure if that is the goal of PDO here is to acutally constrain the
display width, since I occasionally get junk characters after the
specified length.
ie:
+-+
| id mediumint(4) |
+-+
| 123456 |
+-+
value from PDO is '1234', but sometimes is '1234Àd' or other junk
characters.
Reproduce code:
---
$c = new PDO(
"mysql:dbname=test;host=localhost", '***', '***'
);
// mysql mediumint
// bytes: 3
// minimum: -8388608 / 0
// maximum: 8388607 / 16777215
$c->exec('CREATE TABLE IF NOT EXISTS foo (id mediumint(4), primary key
(id));');
$c->exec("INSERT INTO foo VALUES (12345);");
$c->exec("INSERT INTO foo VALUES (1234567);");
$stmt = $c->prepare("SELECT * FROM foo");
$stmt->execute();
print_r($stmt->fetchAll());
Expected result:
Array
(
[0] => Array
(
[id] => 12345
[0] => 12345
)
[1] => Array
(
[id] => 1234567
[0] => 1234567
)
)
Actual result:
--
Array
(
[0] => Array
(
[id] => 1234
[0] => 1234
)
[1] => Array
(
[id] => 1234
[0] => 1234
)
)
--- or sometimes
Array
(
[0] => Array
(
[id] => 1234À
[0] => 1234À
)
[1] => Array
(
[id] => 1234ÀdL
[0] => 1234ÀdL
)
)
--
Edit bug report at http://bugs.php.net/?id=34001&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34001&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34001&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34001&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34001&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34001&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34001&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34001&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34001&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34001&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34001&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34001&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34001&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34001&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34001&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34001&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34001&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34001&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34001&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34001&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34001&r=mysqlcfg
#33991 [Fbk->Opn]: Bug test #25665 fails on Solaris
ID: 33991
User updated by: akim at freedom dot com
Reported By: akim at freedom dot com
-Status: Feedback
+Status: Open
Bug Type: Math related
Operating System: Solaris 2.9 / SPARC
PHP Version: 5CVS-2005-08-05
New Comment:
Output:
bash-2.05$ php -r 'var_dump(is_nan(acos(1.01)));'
bool(false)
I also cooked this up to test the hypothesis:
#include
#include
void main()
{
double a;
a = 1.01;
printf("The value of acos(%f) is %f\n", a, acos(a));
}
Output from this is:
The value of acos(1.01) is 0.00
Previous Comments:
[2005-08-05 01:07:29] [EMAIL PROTECTED]
What does this output for you:
# php -r 'var_dump(is_nan(acos(1.01)));'
[2005-08-04 19:29:30] akim at freedom dot com
Same results with latest snapshot.
[2005-08-04 08:43:08] [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
[2005-08-04 02:19:08] akim at freedom dot com
Description:
acos() function returns "0" rather than "NAN" for values of |x| > 1.
Among other things this causes test
ext/standard/tests/math/bug25665.phpt to fail.
This may be caused by ambiguous handling of out-of-range arguments in
the Solaris implementation of acos(). From the acos() man page: "If the
value of x is not in the range [-1,1], and is not +-Inf or NaN, either
0.0 or NaN is returned and errno is set to EDOM."
Configure line:
./configure --with-apxs=/www/apache/bin/apxs
--with-mssql=/www/freetds063 --enable-ftp
Dependencies:
libsybdb.so.5 => /www/freetds063/lib/libsybdb.so.5
libnsl.so.1 => /lib/libnsl.so.1
libsocket.so.1 =>/lib/libsocket.so.1
libc.so.1 => /lib/libc.so.1
libresolv.so.2 =>/lib/libresolv.so.2
libm.so.1 => /lib/libm.so.1
libdl.so.1 =>/lib/libdl.so.1
libz.so.1 => /lib/libz.so.1
libxml2.so.2 => /usr/local/lib/libxml2.so.2
libpthread.so.1 => /lib/libpthread.so.1
libiconv.so.2 => /usr/local/lib/libiconv.so.2
libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1
libmp.so.2 =>/lib/libmp.so.2
/usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1
libthread.so.1 =>/lib/libthread.so.1
librt.so.1 =>/lib/librt.so.1
libaio.so.1 => /lib/libaio.so.1
libmd5.so.1 => /lib/libmd5.so.1
/usr/platform/SUNW,UltraAX-i2/lib/libmd5_psr.so.1
gcc -v output:
Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --disable-nls
Thread model: posix
gcc version 3.4.2
Reproduce code:
---
Expected result:
float(NAN)
float(-INF)
Actual result:
--
float(0)
float(-INF)
--
Edit this bug report at http://bugs.php.net/?id=33991&edit=1
#33997 [Asn->Csd]: Returned: Bug #16069 - ICONV transliteration failure
ID: 33997 User updated by: RVaughn at pheedo dot com Reported By: RVaughn at pheedo dot com -Status: Assigned +Status: Closed Bug Type: ICONV related Operating System: Red Hat Ent. 3.0 PHP Version: 5CVS, 4CVS (2005-08-04) Assigned To: yohgaki New Comment: Works perfectly! Hopefully this patch can be rolled into PHP 4.4.1? This one can be closed, that was the fix. Thanks much! Cheers! Previous Comments: [2005-08-05 00:39:44] [EMAIL PROTECTED] This seems to fix the problem: http://www.php.net/~jani/patches/bug33997.patch I now get the correct result which I also got with the command line iconv tool. [2005-08-04 23:34:18] RVaughn at pheedo dot com Do let me know if you want me to put the output somewhere on our site where it can be downloaded, the code itself is just the PHP-provided test: bug16069.phpt. Thanks! Cheers! [2005-08-04 23:32:57] RVaughn at pheedo dot com OK, here's the diff output from the test results, please note that the output is the same until part way through, and the ultimate length is different: === /usr/local/src/Tars/php-4.4.0/ext/iconv/tests/bug16069.phpt === EXPECTED OUTPUT ¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë) ACTUAL OUTPUT ¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë) FAILED [2005-08-04 22:42:12] [EMAIL PROTECTED] If it fails, you should get *.diff file which clearly shows what did you get instead of the result expected. And you don't have to post something, you can just put the code and it's output somewhere in the Net and post a link here. [2005-08-04 22:29:10] RVaughn at pheedo dot com Q: How exactly does it fail. A: Cannot reproduce here, as it's a string of Japanese multi-byte characters which would just be garbage if cut and pasted here. All I can say is that any char buffer string of a size greater than 50? 60? bytes long gets scrambled after that point, everything is fine up to it but not after. There's no way for me to post the Japanese characters and since I don't speak Japanese, I am going on our developer in Japan's testing, and he says that short strings are translating fine but longer ones get garbled around that point. Sorry that I can't provide more detailed info and cannot give you an example, but if you run the test script in the PHP test suite as I mentioned on this platform, you will get the same failure and the fact that a PHP-provided test is failing should be enough to (1) reopen the original bug #16069 as unresolved on this platform and (2) provide a way to go about seeing the failure and trying to figure it out. 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/33997 -- Edit this bug report at http://bugs.php.net/?id=33997&edit=1
#34000 [Fbk->Opn]: parameters not passwed correctly
ID: 34000
User updated by: shim at andersens dot org
Reported By: shim at andersens dot org
-Status: Feedback
+Status: Open
Bug Type: Class/Object related
Operating System: FC3
PHP Version: 4.3.11
New Comment:
I havent tried the CVS version because I dont have access to a dev
server to compile the CVS version. Sorry.
Previous Comments:
[2005-08-05 01:00:27] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Why didn't you try it before?
[2005-08-05 00:53:17] shim at andersens dot org
Traced it down to a line that read
params[$name];
}
?>
changing it to
...
$v = $this->params[$name];
return $v;
...
fixes it. Is this the same issue fixed in 4.4?
[2005-08-05 00:35:11] [EMAIL PROTECTED]
Your code works perfectly fine here.
Please provide the real one.
[2005-08-05 00:27:08] shim at nadersens dot org
foo('a','b',c')
should be
foo('a','b','c')
also, are varibables are references to eachother. Changing one changes
them all.
[2005-08-05 00:16:23] [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 ,
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 to avoid embedding huge scripts into the report.
The code you have provided basically doesn't work (missing quotes and
semicolons).
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/34000
--
Edit this bug report at http://bugs.php.net/?id=34000&edit=1
#33991 [Opn->Fbk]: Bug test #25665 fails on Solaris
ID: 33991 Updated by: [EMAIL PROTECTED] Reported By: akim at freedom dot com -Status: Open +Status: Feedback Bug Type: Math related Operating System: Solaris 2.9 / SPARC PHP Version: 5.0.4 New Comment: What does this output for you: # php -r 'var_dump(is_nan(acos(1.01)));' Previous Comments: [2005-08-04 19:29:30] akim at freedom dot com Same results with latest snapshot. [2005-08-04 08:43:08] [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 [2005-08-04 02:19:08] akim at freedom dot com Description: acos() function returns "0" rather than "NAN" for values of |x| > 1. Among other things this causes test ext/standard/tests/math/bug25665.phpt to fail. This may be caused by ambiguous handling of out-of-range arguments in the Solaris implementation of acos(). From the acos() man page: "If the value of x is not in the range [-1,1], and is not +-Inf or NaN, either 0.0 or NaN is returned and errno is set to EDOM." Configure line: ./configure --with-apxs=/www/apache/bin/apxs --with-mssql=/www/freetds063 --enable-ftp Dependencies: libsybdb.so.5 => /www/freetds063/lib/libsybdb.so.5 libnsl.so.1 => /lib/libnsl.so.1 libsocket.so.1 =>/lib/libsocket.so.1 libc.so.1 => /lib/libc.so.1 libresolv.so.2 =>/lib/libresolv.so.2 libm.so.1 => /lib/libm.so.1 libdl.so.1 =>/lib/libdl.so.1 libz.so.1 => /lib/libz.so.1 libxml2.so.2 => /usr/local/lib/libxml2.so.2 libpthread.so.1 => /lib/libpthread.so.1 libiconv.so.2 => /usr/local/lib/libiconv.so.2 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libmp.so.2 =>/lib/libmp.so.2 /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1 libthread.so.1 =>/lib/libthread.so.1 librt.so.1 =>/lib/librt.so.1 libaio.so.1 => /lib/libaio.so.1 libmd5.so.1 => /lib/libmd5.so.1 /usr/platform/SUNW,UltraAX-i2/lib/libmd5_psr.so.1 gcc -v output: Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.4.2 Reproduce code: --- Expected result: float(NAN) float(-INF) Actual result: -- float(0) float(-INF) -- Edit this bug report at http://bugs.php.net/?id=33991&edit=1
#34000 [Opn->Fbk]: parameters not passwed correctly
ID: 34000
Updated by: [EMAIL PROTECTED]
Reported By: shim at andersens dot org
-Status: Open
+Status: Feedback
Bug Type: Class/Object related
Operating System: FC3
PHP Version: 4.3.11
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Why didn't you try it before?
Previous Comments:
[2005-08-05 00:53:17] shim at andersens dot org
Traced it down to a line that read
params[$name];
}
?>
changing it to
...
$v = $this->params[$name];
return $v;
...
fixes it. Is this the same issue fixed in 4.4?
[2005-08-05 00:35:11] [EMAIL PROTECTED]
Your code works perfectly fine here.
Please provide the real one.
[2005-08-05 00:27:08] shim at nadersens dot org
foo('a','b',c')
should be
foo('a','b','c')
also, are varibables are references to eachother. Changing one changes
them all.
[2005-08-05 00:16:23] [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 ,
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 to avoid embedding huge scripts into the report.
The code you have provided basically doesn't work (missing quotes and
semicolons).
[2005-08-05 00:10:21] shim at andersens dot org
Description:
Passing Parameters to a function result in all parameters and variables
being set to the last paramter.
I'd like to submit a ziped of sample of code that does this, but I'm
haven't been able to extract the broken code from my program yet. It
works sometimes, but not others.
Seems to depend on the number of classes I have included.
I'll update this when I have a working (broken) sample.
Reproduce code:
---
foo('a','b',c')
function foo( $a, $b, $c)
{
echo $a;
echo $b;
echo $c;
echo $d; // new varible
}
Expected result:
abc
Actual result:
--
-- Notice $d is also set to 'c'
--
Edit this bug report at http://bugs.php.net/?id=34000&edit=1
#34000 [Fbk->Opn]: parameters not passwed correctly
ID: 34000
User updated by: shim at andersens dot org
-Reported By: shim at nadersens dot org
+Reported By: shim at andersens dot org
-Status: Feedback
+Status: Open
Bug Type: Class/Object related
Operating System: FC3
PHP Version: 4.3.11
New Comment:
Traced it down to a line that read
params[$name];
}
?>
changing it to
...
$v = $this->params[$name];
return $v;
...
fixes it. Is this the same issue fixed in 4.4?
Previous Comments:
[2005-08-05 00:35:11] [EMAIL PROTECTED]
Your code works perfectly fine here.
Please provide the real one.
[2005-08-05 00:27:08] shim at nadersens dot org
foo('a','b',c')
should be
foo('a','b','c')
also, are varibables are references to eachother. Changing one changes
them all.
[2005-08-05 00:16:23] [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 ,
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 to avoid embedding huge scripts into the report.
The code you have provided basically doesn't work (missing quotes and
semicolons).
[2005-08-05 00:10:21] shim at andersens dot org
Description:
Passing Parameters to a function result in all parameters and variables
being set to the last paramter.
I'd like to submit a ziped of sample of code that does this, but I'm
haven't been able to extract the broken code from my program yet. It
works sometimes, but not others.
Seems to depend on the number of classes I have included.
I'll update this when I have a working (broken) sample.
Reproduce code:
---
foo('a','b',c')
function foo( $a, $b, $c)
{
echo $a;
echo $b;
echo $c;
echo $d; // new varible
}
Expected result:
abc
Actual result:
--
-- Notice $d is also set to 'c'
--
Edit this bug report at http://bugs.php.net/?id=34000&edit=1
#33997 [Opn->Asn]: Returned: Bug #16069 - ICONV transliteration failure
ID: 33997 Updated by: [EMAIL PROTECTED] Reported By: RVaughn at pheedo dot com -Status: Open +Status: Assigned Bug Type: ICONV related Operating System: Red Hat Ent. 3.0 -PHP Version: 4.4.0 +PHP Version: 5CVS, 4CVS (2005-08-04) -Assigned To: +Assigned To: yohgaki New Comment: This seems to fix the problem: http://www.php.net/~jani/patches/bug33997.patch I now get the correct result which I also got with the command line iconv tool. Previous Comments: [2005-08-04 23:34:18] RVaughn at pheedo dot com Do let me know if you want me to put the output somewhere on our site where it can be downloaded, the code itself is just the PHP-provided test: bug16069.phpt. Thanks! Cheers! [2005-08-04 23:32:57] RVaughn at pheedo dot com OK, here's the diff output from the test results, please note that the output is the same until part way through, and the ultimate length is different: === /usr/local/src/Tars/php-4.4.0/ext/iconv/tests/bug16069.phpt === EXPECTED OUTPUT ¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë) ACTUAL OUTPUT ¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë) FAILED [2005-08-04 22:42:12] [EMAIL PROTECTED] If it fails, you should get *.diff file which clearly shows what did you get instead of the result expected. And you don't have to post something, you can just put the code and it's output somewhere in the Net and post a link here. [2005-08-04 22:29:10] RVaughn at pheedo dot com Q: How exactly does it fail. A: Cannot reproduce here, as it's a string of Japanese multi-byte characters which would just be garbage if cut and pasted here. All I can say is that any char buffer string of a size greater than 50? 60? bytes long gets scrambled after that point, everything is fine up to it but not after. There's no way for me to post the Japanese characters and since I don't speak Japanese, I am going on our developer in Japan's testing, and he says that short strings are translating fine but longer ones get garbled around that point. Sorry that I can't provide more detailed info and cannot give you an example, but if you run the test script in the PHP test suite as I mentioned on this platform, you will get the same failure and the fact that a PHP-provided test is failing should be enough to (1) reopen the original bug #16069 as unresolved on this platform and (2) provide a way to go about seeing the failure and trying to figure it out. Thanks! [2005-08-04 22:25:09] RVaughn at pheedo dot com Was getting one warning in the 'make' output as reported, fixed the code in: .../php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c and now do not get a warning in the 'make' but it did not fix the problem, and multi-byte string output for Japanese text is being messed up by this reopened? never-fixed? bug. Here's the diff to fix the warning for encodings.c, very simple: 64c64 < char const *src_ptr = src; --- > char* src_ptr = (char*) src; It clearly states the iconv() parameters and you can't pass a 'const' into the call, period. 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/33997 -- Edit this bug report at http://bugs.php.net/?id=33997&edit=1
#34000 [Opn->Fbk]: parameters not passwed correctly
ID: 34000
Updated by: [EMAIL PROTECTED]
Reported By: shim at nadersens dot org
-Status: Open
+Status: Feedback
Bug Type: Class/Object related
Operating System: FC3
PHP Version: 4.3.11
New Comment:
Your code works perfectly fine here.
Please provide the real one.
Previous Comments:
[2005-08-05 00:27:08] shim at nadersens dot org
foo('a','b',c')
should be
foo('a','b','c')
also, are varibables are references to eachother. Changing one changes
them all.
[2005-08-05 00:16:23] [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 ,
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 to avoid embedding huge scripts into the report.
The code you have provided basically doesn't work (missing quotes and
semicolons).
[2005-08-05 00:10:21] shim at nadersens dot org
Description:
Passing Parameters to a function result in all parameters and variables
being set to the last paramter.
I'd like to submit a ziped of sample of code that does this, but I'm
haven't been able to extract the broken code from my program yet. It
works sometimes, but not others.
Seems to depend on the number of classes I have included.
I'll update this when I have a working (broken) sample.
Reproduce code:
---
foo('a','b',c')
function foo( $a, $b, $c)
{
echo $a;
echo $b;
echo $c;
echo $d; // new varible
}
Expected result:
abc
Actual result:
--
-- Notice $d is also set to 'c'
--
Edit this bug report at http://bugs.php.net/?id=34000&edit=1
#34000 [Fbk->Opn]: parameters not passwed correctly
ID: 34000
User updated by: shim at nadersens dot org
Reported By: shim at nadersens dot org
-Status: Feedback
+Status: Open
Bug Type: Class/Object related
Operating System: FC3
PHP Version: 4.3.11
New Comment:
foo('a','b',c')
should be
foo('a','b','c')
also, are varibables are references to eachother. Changing one changes
them all.
Previous Comments:
[2005-08-05 00:16:23] [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 ,
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 to avoid embedding huge scripts into the report.
The code you have provided basically doesn't work (missing quotes and
semicolons).
[2005-08-05 00:10:21] shim at nadersens dot org
Description:
Passing Parameters to a function result in all parameters and variables
being set to the last paramter.
I'd like to submit a ziped of sample of code that does this, but I'm
haven't been able to extract the broken code from my program yet. It
works sometimes, but not others.
Seems to depend on the number of classes I have included.
I'll update this when I have a working (broken) sample.
Reproduce code:
---
foo('a','b',c')
function foo( $a, $b, $c)
{
echo $a;
echo $b;
echo $c;
echo $d; // new varible
}
Expected result:
abc
Actual result:
--
-- Notice $d is also set to 'c'
--
Edit this bug report at http://bugs.php.net/?id=34000&edit=1
#34000 [Opn->Fbk]: parameters not passwed correctly
ID: 34000
Updated by: [EMAIL PROTECTED]
Reported By: shim at nadersens dot org
-Status: Open
+Status: Feedback
Bug Type: Class/Object related
Operating System: FC3
PHP Version: 4.3.11
New Comment:
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 ,
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 to avoid embedding huge scripts into the report.
The code you have provided basically doesn't work (missing quotes and
semicolons).
Previous Comments:
[2005-08-05 00:10:21] shim at nadersens dot org
Description:
Passing Parameters to a function result in all parameters and variables
being set to the last paramter.
I'd like to submit a ziped of sample of code that does this, but I'm
haven't been able to extract the broken code from my program yet. It
works sometimes, but not others.
Seems to depend on the number of classes I have included.
I'll update this when I have a working (broken) sample.
Reproduce code:
---
foo('a','b',c')
function foo( $a, $b, $c)
{
echo $a;
echo $b;
echo $c;
echo $d; // new varible
}
Expected result:
abc
Actual result:
--
-- Notice $d is also set to 'c'
--
Edit this bug report at http://bugs.php.net/?id=34000&edit=1
#33994 [WFx]: DB unavailable after forked child exits
ID: 33994
User updated by: greatwhitepine at bigfoot dot com
Reported By: greatwhitepine at bigfoot dot com
Status: Wont fix
Bug Type: Ingres II related
Operating System: Tru64 UNIX V5.1B (Rev. 2650)
PHP Version: 5.0.4
New Comment:
Just in case anyone might care I have a workaround... the parent must
not open a db connection until all children have completed. Thus if
the parent needs to use the db before forking child processes it should
fork a db_child process to do so.
This code works as expected...
print 'parent before parent query'."\n\n";
$int_pid = pcntl_fork();
if(!$int_pid) {
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from auto_ldg_run')) {
print 'db ok for for parent query'."\n\n";
}
exit();
}
pcntl_waitpid($int_pid, $int_returnCode, WUNTRACED);
print 'parent before child process is spawned'."\n\n";
$arr_pids = FALSE;
for ($i=0; $i < 3; $i++) {
$arr_pids[] = pcntl_fork();
if(!$arr_pids[$i]) {
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from auto_ldg_run')) {
print 'db ok for child '.$i." \n\n";
}
exit();
}
}
for ($i=0; $i < 3; $i++) {
pcntl_waitpid($arr_pids[$i], $int_returnCode, WUNTRACED);
}
print 'parent after children have completed'."\n\n";
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from auto_ldg_run')) {
print 'db ok for parent after children have completed'."\n\n";
}
Output...
parent before parent query
db ok for for parent query
parent before child process is spawned
db ok for child 0
db ok for child 1
db ok for child 2
parent after children have completed
db ok for parent after children have completed
Previous Comments:
[2005-08-04 18:39:52] greatwhitepine at bigfoot dot com
Seperate connections does not work (as per the example)!
[2005-08-04 08:45:38] [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
Use separate connections or something else than ingres (moved to PECL,
report bugs on it to pecl.php.net/bugs..)
[2005-08-04 08:14:13] greatwhitepine at bigfoot dot com
Sorry, forgot the pcntl_waitpid during my 1st edit (see below).
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from auto_ldg_run')) {
print 'db ok during fork'."\n\n";
}
$int_pid = pcntl_fork();
if(!$int_pid) {
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from auto_ldg_run')) {
print 'db ok for child'."\n\n";
}
exit();
}
pcntl_waitpid ($int_pid, $str_status);
ingres_connect($str_database, $str_username, $str_password);
if (!ingres_query('select count(*) from auto_ldg_run')) {
print 'db not ok after fork'."\n\n";
}
exit(1);
[2005-08-04 08:03:06] greatwhitepine at bigfoot dot com
Description:
As per the manual ingres_connect connections are terminated when the
process exits. When a forked child exits the connection is terminated
permanently until the parent process is restarted.
Reproduce code:
---
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from table')) {
print 'db ok during fork'."\n\n";
}
$int_pid = pcntl_fork();
if(!$int_pid) {
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from table')) {
print 'db ok for child'."\n\n";
}
exit();
}
ingres_connect($str_database, $str_username, $str_password);
if (!ingres_query('select count(*) from table')) {
print 'db not ok after fork'."\n\n";
}
Expected result:
db ok during fork
db ok for child
Actual result:
--
db ok during fork
db ok for child
Warning: ingres_query(): Ingres II: Server or API error : Read from
peer process failed; it may have exited. in
/home/its/autoldg/lib/php/local/lib_autoldg_daemon.php on line 228
Warning: ingres_query(): Ingres II: SQLSTATE : 08004 in
/home/its/autoldg/lib/php/local/lib_autoldg_daemon.php on line 228
db not ok after fork
Warning: Unknown: Ingres II: Server or API error : API function cannot
be called in the current state. in Unknown on line 0
Warning: Unknown: Ingres II: SQLSTATE : 5000R in Unknown on line 0
Warning: Unknown: Ingres II: Unable to close statement !! in Unknown
on line 0
Warning: Unknown: Ingres II: Unable to rollback transaction !! in
Unknown on line 0
-
#34000 [NEW]: parameters not passwed correctly
From: shim at nadersens dot org
Operating system: FC3
PHP version: 4.3.11
PHP Bug Type: Class/Object related
Bug description: parameters not passwed correctly
Description:
Passing Parameters to a function result in all parameters and variables
being set to the last paramter.
I'd like to submit a ziped of sample of code that does this, but I'm
haven't been able to extract the broken code from my program yet. It
works sometimes, but not others.
Seems to depend on the number of classes I have included.
I'll update this when I have a working (broken) sample.
Reproduce code:
---
foo('a','b',c')
function foo( $a, $b, $c)
{
echo $a;
echo $b;
echo $c;
echo $d; // new varible
}
Expected result:
abc
Actual result:
--
-- Notice $d is also set to 'c'
--
Edit bug report at http://bugs.php.net/?id=34000&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34000&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34000&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34000&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34000&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34000&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34000&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34000&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34000&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34000&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34000&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34000&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34000&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34000&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34000&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34000&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34000&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34000&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34000&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34000&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34000&r=mysqlcfg
#33999 [Opn->Asn]: object remains object when cast to int
ID: 33999
Updated by: [EMAIL PROTECTED]
Reported By: crywolf at kyndimarion dot net
-Status: Open
+Status: Assigned
Bug Type: Class/Object related
Operating System: *
PHP Version: 5CVS-2005-08-05
-Assigned To:
+Assigned To: dmitry
New Comment:
Dmitry, I guess we need to return at least objects index in this
case.
Or maybe use the same way we use when compatibility_mode is on.
What do you think?
Previous Comments:
[2005-08-04 23:49:03] crywolf at kyndimarion dot net
Description:
When attempting to cast an object to an int, it remains untouched. No
warnings or errors are displayed. The results are the same for (int),
intval(), and settype(). float, bool, string, and array all seem to
work correctly. I get the same results in both 5.0.3 and 5.1.0b3. In
4.3.11, an object can be cast to int.
Reproduce code:
---
Expected result:
object(Foo)#1 (1) {
["bar"]=>
string(3) "bat"
}
int(1)
float(1)
Actual result:
--
object(Foo)#1 (1) {
["bar"]=>
string(3) "bat"
}
object(Foo)#1 (1) {
["bar"]=>
string(3) "bat"
}
Notice: Object of class Foo could not be converted to double in
/home/crywolf/Test/cast_object.php on line 14
float(1)
--
Edit this bug report at http://bugs.php.net/?id=33999&edit=1
#33999 [NEW]: object remains object when cast to int
From: crywolf at kyndimarion dot net
Operating system: Linux
PHP version: 5.0.3
PHP Bug Type: Class/Object related
Bug description: object remains object when cast to int
Description:
When attempting to cast an object to an int, it remains untouched. No
warnings or errors are displayed. The results are the same for (int),
intval(), and settype(). float, bool, string, and array all seem to work
correctly. I get the same results in both 5.0.3 and 5.1.0b3. In 4.3.11,
an object can be cast to int.
Reproduce code:
---
Expected result:
object(Foo)#1 (1) {
["bar"]=>
string(3) "bat"
}
int(1)
float(1)
Actual result:
--
object(Foo)#1 (1) {
["bar"]=>
string(3) "bat"
}
object(Foo)#1 (1) {
["bar"]=>
string(3) "bat"
}
Notice: Object of class Foo could not be converted to double in
/home/crywolf/Test/cast_object.php on line 14
float(1)
--
Edit bug report at http://bugs.php.net/?id=33999&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33999&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33999&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33999&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33999&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33999&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33999&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33999&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33999&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33999&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33999&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33999&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33999&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33999&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33999&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33999&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33999&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33999&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33999&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33999&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33999&r=mysqlcfg
#33997 [Opn]: Returned: Bug #16069 - ICONV transliteration failure
ID: 33997 User updated by: RVaughn at pheedo dot com Reported By: RVaughn at pheedo dot com Status: Open Bug Type: ICONV related Operating System: Red Hat Ent. 3.0 PHP Version: 4.4.0 New Comment: Do let me know if you want me to put the output somewhere on our site where it can be downloaded, the code itself is just the PHP-provided test: bug16069.phpt. Thanks! Cheers! Previous Comments: [2005-08-04 23:32:57] RVaughn at pheedo dot com OK, here's the diff output from the test results, please note that the output is the same until part way through, and the ultimate length is different: === /usr/local/src/Tars/php-4.4.0/ext/iconv/tests/bug16069.phpt === EXPECTED OUTPUT ¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë) ACTUAL OUTPUT ¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë) FAILED [2005-08-04 22:42:12] [EMAIL PROTECTED] If it fails, you should get *.diff file which clearly shows what did you get instead of the result expected. And you don't have to post something, you can just put the code and it's output somewhere in the Net and post a link here. [2005-08-04 22:29:10] RVaughn at pheedo dot com Q: How exactly does it fail. A: Cannot reproduce here, as it's a string of Japanese multi-byte characters which would just be garbage if cut and pasted here. All I can say is that any char buffer string of a size greater than 50? 60? bytes long gets scrambled after that point, everything is fine up to it but not after. There's no way for me to post the Japanese characters and since I don't speak Japanese, I am going on our developer in Japan's testing, and he says that short strings are translating fine but longer ones get garbled around that point. Sorry that I can't provide more detailed info and cannot give you an example, but if you run the test script in the PHP test suite as I mentioned on this platform, you will get the same failure and the fact that a PHP-provided test is failing should be enough to (1) reopen the original bug #16069 as unresolved on this platform and (2) provide a way to go about seeing the failure and trying to figure it out. Thanks! [2005-08-04 22:25:09] RVaughn at pheedo dot com Was getting one warning in the 'make' output as reported, fixed the code in: .../php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c and now do not get a warning in the 'make' but it did not fix the problem, and multi-byte string output for Japanese text is being messed up by this reopened? never-fixed? bug. Here's the diff to fix the warning for encodings.c, very simple: 64c64 < char const *src_ptr = src; --- > char* src_ptr = (char*) src; It clearly states the iconv() parameters and you can't pass a 'const' into the call, period. [2005-08-04 20:25:57] [EMAIL PROTECTED] How *exactly* does it fail? 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/33997 -- Edit this bug report at http://bugs.php.net/?id=33997&edit=1
#33997 [Fbk->Opn]: Returned: Bug #16069 - ICONV transliteration failure
ID: 33997 User updated by: RVaughn at pheedo dot com Reported By: RVaughn at pheedo dot com -Status: Feedback +Status: Open Bug Type: ICONV related Operating System: Red Hat Ent. 3.0 PHP Version: 4.4.0 New Comment: OK, here's the diff output from the test results, please note that the output is the same until part way through, and the ultimate length is different: === /usr/local/src/Tars/php-4.4.0/ext/iconv/tests/bug16069.phpt === EXPECTED OUTPUT ¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë) ACTUAL OUTPUT ¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë) FAILED Previous Comments: [2005-08-04 22:42:12] [EMAIL PROTECTED] If it fails, you should get *.diff file which clearly shows what did you get instead of the result expected. And you don't have to post something, you can just put the code and it's output somewhere in the Net and post a link here. [2005-08-04 22:29:10] RVaughn at pheedo dot com Q: How exactly does it fail. A: Cannot reproduce here, as it's a string of Japanese multi-byte characters which would just be garbage if cut and pasted here. All I can say is that any char buffer string of a size greater than 50? 60? bytes long gets scrambled after that point, everything is fine up to it but not after. There's no way for me to post the Japanese characters and since I don't speak Japanese, I am going on our developer in Japan's testing, and he says that short strings are translating fine but longer ones get garbled around that point. Sorry that I can't provide more detailed info and cannot give you an example, but if you run the test script in the PHP test suite as I mentioned on this platform, you will get the same failure and the fact that a PHP-provided test is failing should be enough to (1) reopen the original bug #16069 as unresolved on this platform and (2) provide a way to go about seeing the failure and trying to figure it out. Thanks! [2005-08-04 22:25:09] RVaughn at pheedo dot com Was getting one warning in the 'make' output as reported, fixed the code in: .../php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c and now do not get a warning in the 'make' but it did not fix the problem, and multi-byte string output for Japanese text is being messed up by this reopened? never-fixed? bug. Here's the diff to fix the warning for encodings.c, very simple: 64c64 < char const *src_ptr = src; --- > char* src_ptr = (char*) src; It clearly states the iconv() parameters and you can't pass a 'const' into the call, period. [2005-08-04 20:25:57] [EMAIL PROTECTED] How *exactly* does it fail? [2005-08-04 20:23:24] RVaughn at pheedo dot com Description: In the PHP 4.4 test suite, the test for closed bug #16069 fails: FAIL Bug #16069 [ext/iconv/tests/bug16069.phpt] Checked the output and it does diverge from the expected output in the same way the old bug from 2002 did. The 'iconv' libraries are up-to-date on the system: # up2date glibc-common The following packages you requested are already updated: glibc-common # rpm -qi glibc-common Name: glibc-common Relocations: (not relocatable) Version: 2.3.2 Vendor: Red Hat, Inc. Release: 95.33 Build Date: Wed 23 Feb 2005 The bug16069.phpt script will reproduce this every time. Configured with the following settings: ./configure '--host=i386-redhat-linux' '--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-freetype-di
#33996 [Fbk->Asn]: No information given for fatal error on passing invalid value to typed argument
ID: 33996 Updated by: [EMAIL PROTECTED] Reported By: phpbugs at majiclab dot com -Status: Feedback +Status: Assigned Bug Type: Scripting Engine problem Operating System: Mac OSX 10.4 PHP Version: 5.0.4 Assigned To: dmitry New Comment: Nevermind that. I get the same result. (I propably should have eyeglasses or something :) Previous Comments: [2005-08-04 22:20:17] [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 with latest CVS.. [2005-08-04 19:46:03] [EMAIL PROTECTED] Dmitry, could you plz look at it? I can reproduce it with 5.1 too. [2005-08-04 17:43:45] phpbugs at majiclab dot com Description: When passing an invalid value as a typed argument (as in ! ($argument instanceof typedclass)), a Fatal Error is given, with the following information: Fatal error: Argument 1 must be an object of class Foo in index.php on line 7 The problem is line 7 is the declaration of the function, not the line of code that called the function. It makes bug tracing on a big project next to impossible! Even using ZDE Professional has the same results: I cannot find the function that caused the error (and since the error is fatal, there is no more stack for me to look at). The same goes for missing arguments. Reproduce code: --- Expected result: Warning: Missing argument 1 for NormalTest() in /.../index.php on line 17 Hi! Warning: Argument 1 must be an object of class Foo in /.../ index.php on line 18 Actual result: -- Warning: Missing argument 1 for NormalTest() in /.../index.php on line 12 Hi! Fatal error: Argument 1 must be an object of class Foo in /.../index.php on line 7 -- Edit this bug report at http://bugs.php.net/?id=33996&edit=1
#33997 [Opn->Fbk]: Returned: Bug #16069 - ICONV transliteration failure
ID: 33997 Updated by: [EMAIL PROTECTED] Reported By: RVaughn at pheedo dot com -Status: Open +Status: Feedback Bug Type: ICONV related Operating System: Red Hat Ent. 3.0 PHP Version: 4.4.0 New Comment: If it fails, you should get *.diff file which clearly shows what did you get instead of the result expected. And you don't have to post something, you can just put the code and it's output somewhere in the Net and post a link here. Previous Comments: [2005-08-04 22:29:10] RVaughn at pheedo dot com Q: How exactly does it fail. A: Cannot reproduce here, as it's a string of Japanese multi-byte characters which would just be garbage if cut and pasted here. All I can say is that any char buffer string of a size greater than 50? 60? bytes long gets scrambled after that point, everything is fine up to it but not after. There's no way for me to post the Japanese characters and since I don't speak Japanese, I am going on our developer in Japan's testing, and he says that short strings are translating fine but longer ones get garbled around that point. Sorry that I can't provide more detailed info and cannot give you an example, but if you run the test script in the PHP test suite as I mentioned on this platform, you will get the same failure and the fact that a PHP-provided test is failing should be enough to (1) reopen the original bug #16069 as unresolved on this platform and (2) provide a way to go about seeing the failure and trying to figure it out. Thanks! [2005-08-04 22:25:09] RVaughn at pheedo dot com Was getting one warning in the 'make' output as reported, fixed the code in: .../php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c and now do not get a warning in the 'make' but it did not fix the problem, and multi-byte string output for Japanese text is being messed up by this reopened? never-fixed? bug. Here's the diff to fix the warning for encodings.c, very simple: 64c64 < char const *src_ptr = src; --- > char* src_ptr = (char*) src; It clearly states the iconv() parameters and you can't pass a 'const' into the call, period. [2005-08-04 20:25:57] [EMAIL PROTECTED] How *exactly* does it fail? [2005-08-04 20:23:24] RVaughn at pheedo dot com Description: In the PHP 4.4 test suite, the test for closed bug #16069 fails: FAIL Bug #16069 [ext/iconv/tests/bug16069.phpt] Checked the output and it does diverge from the expected output in the same way the old bug from 2002 did. The 'iconv' libraries are up-to-date on the system: # up2date glibc-common The following packages you requested are already updated: glibc-common # rpm -qi glibc-common Name: glibc-common Relocations: (not relocatable) Version: 2.3.2 Vendor: Red Hat, Inc. Release: 95.33 Build Date: Wed 23 Feb 2005 The bug16069.phpt script will reproduce this every time. Configured with the following settings: ./configure '--host=i386-redhat-linux' '--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-aspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--disable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos' '--with-ldap=shared' '--with-mysql=shared,/usr' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-apxs2=/usr/sbin/apxs' Using a standard /etc/php.ini file that works fine under PHP 4.3.6 which we upgraded to several weeks ago and this bug does not appear to be a problem with. Got the following warning (the only one) when doing a 'make': /
#33997 [Opn]: Returned: Bug #16069 - ICONV transliteration failure
ID: 33997 User updated by: RVaughn at pheedo dot com Reported By: RVaughn at pheedo dot com Status: Open Bug Type: ICONV related Operating System: Red Hat Ent. 3.0 PHP Version: 4.4.0 New Comment: Q: How exactly does it fail. A: Cannot reproduce here, as it's a string of Japanese multi-byte characters which would just be garbage if cut and pasted here. All I can say is that any char buffer string of a size greater than 50? 60? bytes long gets scrambled after that point, everything is fine up to it but not after. There's no way for me to post the Japanese characters and since I don't speak Japanese, I am going on our developer in Japan's testing, and he says that short strings are translating fine but longer ones get garbled around that point. Sorry that I can't provide more detailed info and cannot give you an example, but if you run the test script in the PHP test suite as I mentioned on this platform, you will get the same failure and the fact that a PHP-provided test is failing should be enough to (1) reopen the original bug #16069 as unresolved on this platform and (2) provide a way to go about seeing the failure and trying to figure it out. Thanks! Previous Comments: [2005-08-04 22:25:09] RVaughn at pheedo dot com Was getting one warning in the 'make' output as reported, fixed the code in: .../php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c and now do not get a warning in the 'make' but it did not fix the problem, and multi-byte string output for Japanese text is being messed up by this reopened? never-fixed? bug. Here's the diff to fix the warning for encodings.c, very simple: 64c64 < char const *src_ptr = src; --- > char* src_ptr = (char*) src; It clearly states the iconv() parameters and you can't pass a 'const' into the call, period. [2005-08-04 20:25:57] [EMAIL PROTECTED] How *exactly* does it fail? [2005-08-04 20:23:24] RVaughn at pheedo dot com Description: In the PHP 4.4 test suite, the test for closed bug #16069 fails: FAIL Bug #16069 [ext/iconv/tests/bug16069.phpt] Checked the output and it does diverge from the expected output in the same way the old bug from 2002 did. The 'iconv' libraries are up-to-date on the system: # up2date glibc-common The following packages you requested are already updated: glibc-common # rpm -qi glibc-common Name: glibc-common Relocations: (not relocatable) Version: 2.3.2 Vendor: Red Hat, Inc. Release: 95.33 Build Date: Wed 23 Feb 2005 The bug16069.phpt script will reproduce this every time. Configured with the following settings: ./configure '--host=i386-redhat-linux' '--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-aspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--disable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos' '--with-ldap=shared' '--with-mysql=shared,/usr' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-apxs2=/usr/sbin/apxs' Using a standard /etc/php.ini file that works fine under PHP 4.3.6 which we upgraded to several weeks ago and this bug does not appear to be a problem with. Got the following warning (the only one) when doing a 'make': /usr/local/src/Tars/php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c: In function `convert': /usr/local/src/Tars/php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c:74: warning: passing arg 2 of `iconv' from incompatible pointer type Guessing that the call to updated versions of 'libxml' or 'libxml2' is the problem, here's the versions for both: # rpm -qi libxml Name: libxml
#33998 [Opn->Bgs]: Calling a getter within a getter does not work.
ID: 33998
Updated by: [EMAIL PROTECTED]
Reported By: dan at stratitec dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Linux (Red Hat 9)
PHP Version: 5.0.3
New Comment:
>If this is to keep recursion from happening
Yes.
>A programmer can ALWAYS shoot himself
But not THAT easy.
You can encounter infinite recursion every time you try to read
non-existent object property in __get().
This is by design and won't be changed.
Previous Comments:
[2005-08-04 22:22:07] dan at stratitec dot com
Description:
Calling a variable using the __get() code from within a
function that has been called, or is inside the __get()
function itself results in the variable or result not
being found.
If this is to keep recursion from happening, I feel it's a
poor choice. A programmer can ALWAYS shoot himself in the
foot with infinite recursion, but placing limits like this
is counterintuitive and prevents solutions.
Also, since replacing $this->a with $this->__get('a') in
the example allows the script to run as intended, a user
could still use the __get function to recurse infinitely
if their __get() was written improperly.
Reproduce code:
---
class test
{
protected $_a = 6;
function __get($key) {
if($key == 'stuff') {
return $this->stuff();
} else if($key == 'a') {
return $this->_a;
}
}
function stuff()
{
return array('random' => 'key', 'using_getter' => 10 *
$this->a);
}
}
$test = new test();
print 'this should be 60: '.$test->stuff['using_getter'].'';
print 'this should be 6: '.$test->a.'';
Expected result:
this should be 60: 60
this should be 6: 6
Actual result:
--
this should be 60: 0
this should be 6: 6
Also, note, this warning is raised:
[[ Undefined property: test::$a ]]
on /var/www/html/test.php
--
Edit this bug report at http://bugs.php.net/?id=33998&edit=1
#33997 [Fbk->Opn]: Returned: Bug #16069 - ICONV transliteration failure
ID: 33997 User updated by: RVaughn at pheedo dot com Reported By: RVaughn at pheedo dot com -Status: Feedback +Status: Open Bug Type: ICONV related Operating System: Red Hat Ent. 3.0 PHP Version: 4.4.0 New Comment: Was getting one warning in the 'make' output as reported, fixed the code in: .../php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c and now do not get a warning in the 'make' but it did not fix the problem, and multi-byte string output for Japanese text is being messed up by this reopened? never-fixed? bug. Here's the diff to fix the warning for encodings.c, very simple: 64c64 < char const *src_ptr = src; --- > char* src_ptr = (char*) src; It clearly states the iconv() parameters and you can't pass a 'const' into the call, period. Previous Comments: [2005-08-04 20:25:57] [EMAIL PROTECTED] How *exactly* does it fail? [2005-08-04 20:23:24] RVaughn at pheedo dot com Description: In the PHP 4.4 test suite, the test for closed bug #16069 fails: FAIL Bug #16069 [ext/iconv/tests/bug16069.phpt] Checked the output and it does diverge from the expected output in the same way the old bug from 2002 did. The 'iconv' libraries are up-to-date on the system: # up2date glibc-common The following packages you requested are already updated: glibc-common # rpm -qi glibc-common Name: glibc-common Relocations: (not relocatable) Version: 2.3.2 Vendor: Red Hat, Inc. Release: 95.33 Build Date: Wed 23 Feb 2005 The bug16069.phpt script will reproduce this every time. Configured with the following settings: ./configure '--host=i386-redhat-linux' '--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-aspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--disable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos' '--with-ldap=shared' '--with-mysql=shared,/usr' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-apxs2=/usr/sbin/apxs' Using a standard /etc/php.ini file that works fine under PHP 4.3.6 which we upgraded to several weeks ago and this bug does not appear to be a problem with. Got the following warning (the only one) when doing a 'make': /usr/local/src/Tars/php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c: In function `convert': /usr/local/src/Tars/php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c:74: warning: passing arg 2 of `iconv' from incompatible pointer type Guessing that the call to updated versions of 'libxml' or 'libxml2' is the problem, here's the versions for both: # rpm -qi libxml Name: libxml Relocations: (not relocatable) Version: 1.8.17 Vendor: Red Hat, Inc. Release: 9.2 Build Date: Wed 17 Nov 2004 # rpm -qi libxml2 Name: libxml2Relocations: /usr Version: 2.5.10 Vendor: Red Hat, Inc. Release: 7 Build Date: Wed 27 Oct 2004 Reproduce code: --- Please use .../ext/iconv/tests/bug16069.phpt in the test suite. Expected result: The output returned does not match expected results. Actual result: -- This bug *cannot* be safely ignored as per the "Won't Fix" status in Bug #32367 because it is breaking our ability to use Japanese characters in our application with the 'mbstring' libraries. As long as we use English it's fine, but it blows up our Japanese translations (via Smarty templates.) Please do not claim it can be ignored or is a "Won't Fix" as multi-language support is becoming more and more necessary with PHP and this bug is causing major problems with it.
#33998 [NEW]: Calling a getter within a getter does not work.
From: dan at stratitec dot com
Operating system: Linux (Red Hat 9)
PHP version: 5.0.3
PHP Bug Type: Class/Object related
Bug description: Calling a getter within a getter does not work.
Description:
Calling a variable using the __get() code from within a
function that has been called, or is inside the __get()
function itself results in the variable or result not
being found.
If this is to keep recursion from happening, I feel it's a
poor choice. A programmer can ALWAYS shoot himself in the
foot with infinite recursion, but placing limits like this
is counterintuitive and prevents solutions.
Also, since replacing $this->a with $this->__get('a') in
the example allows the script to run as intended, a user
could still use the __get function to recurse infinitely
if their __get() was written improperly.
Reproduce code:
---
class test
{
protected $_a = 6;
function __get($key) {
if($key == 'stuff') {
return $this->stuff();
} else if($key == 'a') {
return $this->_a;
}
}
function stuff()
{
return array('random' => 'key', 'using_getter' => 10 * $this->a);
}
}
$test = new test();
print 'this should be 60: '.$test->stuff['using_getter'].'';
print 'this should be 6: '.$test->a.'';
Expected result:
this should be 60: 60
this should be 6: 6
Actual result:
--
this should be 60: 0
this should be 6: 6
Also, note, this warning is raised:
[[ Undefined property: test::$a ]]
on /var/www/html/test.php
--
Edit bug report at http://bugs.php.net/?id=33998&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33998&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33998&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33998&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33998&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33998&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33998&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33998&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33998&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33998&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33998&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33998&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33998&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33998&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33998&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33998&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33998&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33998&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33998&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33998&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33998&r=mysqlcfg
#33996 [Asn->Fbk]: No information given for fatal error on passing invalid value to typed argument
ID: 33996 Updated by: [EMAIL PROTECTED] Reported By: phpbugs at majiclab dot com -Status: Assigned +Status: Feedback Bug Type: Scripting Engine problem Operating System: Mac OSX 10.4 PHP Version: 5.0.4 Assigned To: dmitry New Comment: 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 with latest CVS.. Previous Comments: [2005-08-04 19:46:03] [EMAIL PROTECTED] Dmitry, could you plz look at it? I can reproduce it with 5.1 too. [2005-08-04 17:43:45] phpbugs at majiclab dot com Description: When passing an invalid value as a typed argument (as in ! ($argument instanceof typedclass)), a Fatal Error is given, with the following information: Fatal error: Argument 1 must be an object of class Foo in index.php on line 7 The problem is line 7 is the declaration of the function, not the line of code that called the function. It makes bug tracing on a big project next to impossible! Even using ZDE Professional has the same results: I cannot find the function that caused the error (and since the error is fatal, there is no more stack for me to look at). The same goes for missing arguments. Reproduce code: --- Expected result: Warning: Missing argument 1 for NormalTest() in /.../index.php on line 17 Hi! Warning: Argument 1 must be an object of class Foo in /.../ index.php on line 18 Actual result: -- Warning: Missing argument 1 for NormalTest() in /.../index.php on line 12 Hi! Fatal error: Argument 1 must be an object of class Foo in /.../index.php on line 7 -- Edit this bug report at http://bugs.php.net/?id=33996&edit=1
#33995 [Opn->Fbk]: wrong WARNING message
ID: 33995 Updated by: [EMAIL PROTECTED] Reported By: zxc at zmail dot ru -Status: Open +Status: Feedback Bug Type: FTP related Operating System: Win2000 SP4 PHP Version: 4.4.0 New Comment: You have to provide a working script. The one here can not work: ftp_login() expects 3 parameters, not 2.. (and I can't reproduce this with a proper script, even if the server shows errors) Previous Comments: [2005-08-04 19:59:47] zxc at zmail dot ru Tony, I has tried change a FTP server to something, but I show WARNING still. [2005-08-04 19:56:42] zxc at zmail dot ru Example of WARNING: -- Warning: ftp_login(): Too many users - please try again later. in /pub/home/hissite/ftpconnect.php on line 73 -- Why shows a WARNING message? I use a "@" prefix before "ftp_login()" function. >>> I must have boolean FALSE only, without this WARNING. [2005-08-04 15:18:54] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. What warning? Which FTP server do you use? How to reproduce it? Are you able to reproduce it if you change your FTP server to something else? [2005-08-04 15:09:13] zxc at zmail dot ru Description: I have a WARNING message from ftp_login(), but I use a "@" with ftp_login() function. Function ftp_login() in this case must returns boolean FALSE only without WARNING. Reproduce code: --- Expected result: I have a WARNING message from ftp_login(), but I use a "@" with ftp_login() function. Function ftp_login() in this case must returns boolean FALSE only without WARNING. Actual result: -- empty screen -- Edit this bug report at http://bugs.php.net/?id=33995&edit=1
#28227 [Com]: PHP CGI depends upon non-standard SCRIPT_FILENAME
ID: 28227 Comment by: pgf at foxharp dot boston dot ma dot us Reported By: lukem at NetBSD dot org Status: Assigned Bug Type: CGI related Operating System: * PHP Version: 5CVS, 4CVS (2005-02-04) Assigned To: fmk New Comment: why hasn't this been fixed? is there a real problem with fixing it? i'm faced with a bug report against the busybox web server that i'd rather not fix, given that the problem is clearly a php problem. Previous Comments: [2005-07-26 05:24:44] joey at clean dot q7 dot com it took me many hours of poking around to finally find this page to figure out why php isn't working under the httpd server provided under busybox. php is clearly doing the wrong thing with respect to the cgi specification. SCRIPT_FILENAME is not a standard header and can not be relied on to function. [2005-05-30 18:33:55] masta at yazzy dot org I ran into this exact same issue with php4-cgi (ver 4.3.11) on FreeBSD due to the SCRIPT_FILENAME problem. I found two ways to avoid the non-standard CGI var is to hack the http server used (mini_httpd) or use LukeM's modifications to php4. Considering that CGI is a standards based domain, modification of the webserver to support non-standard CGI variables is not proper, thus the modification to PHP itself is the solution. I found that the the LukeM modification still allows for proper execution in apache. Can somebody in the php team fix this please? [2005-02-11 03:04:50] [EMAIL PROTECTED] The provided patch was not correct, according to Frank. Assigning to him for now. [2004-12-17 03:02:28] lukem at NetBSD dot org This bug is still present in 4.3.10 as well. Note that NetBSD's pkgsrc system has been using the patch I provided for a few months now, and we haven't received any reports of problems with PHP with that patch when running as a: * php.so module under Apache * php CGI under Apache * php CGI under web servers that don't support the non-standard SCRIPT_FILENAME Please consider applying this patch, because without it PHP is useless as a CGI except under Apache & IIS. [2004-12-13 20:33:52] jbardin at hsc dot usf dot edu Problem still exists in PHP-5.0.2 on SunOS 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/28227 -- Edit this bug report at http://bugs.php.net/?id=28227&edit=1
#32589 [Asn]: imap_mail_compose doesn´t work properly
ID: 32589 User updated by: svoboda at svoon dot net Reported By: svoboda at svoon dot net Status: Assigned Bug Type: IMAP related Operating System: debian PHP Version: 5CVS, 4CVS (2005-07-20) Assigned To: iliaa New Comment: I would like to ask how abou solving this bug. thank you Previous Comments: [2005-07-20 20:46:05] [EMAIL PROTECTED] Verified, assigned to Ilia who was suppose to FIX this before. :) [2005-07-20 13:48:01] svoboda at svoon dot net hello, I have identified, if I compile PHP with --enable-debug option in configure line, then the imap_mail_compose function works perfect. Would you like me to send you GDB with or without --enable-debug option? thank you Ondrej [2005-07-20 09:57:46] [EMAIL PROTECTED] 4.4.0 works fine for me. Provide a GDB backtrace of the crash. [2005-07-20 08:48:42] svoboda at svoon dot net Hello, have you red my text carefuly? I wrote, that version php4-STABLE-200412272330 was OK, but not, that this snapshost is version 4.4.0. This snapshot, as You can see in his name, is a half year old and I wrote it only becouse of explaining, that on the same system with the same configuration command the old version works well, and the new version does not. btw. You can be sure I am using all versions downloaded from php.net - strictli speaking from http://cz.php.net/get/php-4.4.0.tar.gz/from/cz.php.net/mirror ie. Ondrej. [2005-07-19 21:17:57] [EMAIL PROTECTED] You're not really using PHP 4.4.0 downloaded from php.net. The snapshot and release packages do NOT differ anywhere near IMAP stuff. 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/32589 -- Edit this bug report at http://bugs.php.net/?id=32589&edit=1
#33997 [Opn->Fbk]: Returned: Bug #16069 - ICONV transliteration failure
ID: 33997 Updated by: [EMAIL PROTECTED] Reported By: RVaughn at pheedo dot com -Status: Open +Status: Feedback Bug Type: ICONV related Operating System: Red Hat Ent. 3.0 PHP Version: 4.4.0 New Comment: How *exactly* does it fail? Previous Comments: [2005-08-04 20:23:24] RVaughn at pheedo dot com Description: In the PHP 4.4 test suite, the test for closed bug #16069 fails: FAIL Bug #16069 [ext/iconv/tests/bug16069.phpt] Checked the output and it does diverge from the expected output in the same way the old bug from 2002 did. The 'iconv' libraries are up-to-date on the system: # up2date glibc-common The following packages you requested are already updated: glibc-common # rpm -qi glibc-common Name: glibc-common Relocations: (not relocatable) Version: 2.3.2 Vendor: Red Hat, Inc. Release: 95.33 Build Date: Wed 23 Feb 2005 The bug16069.phpt script will reproduce this every time. Configured with the following settings: ./configure '--host=i386-redhat-linux' '--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-aspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--disable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos' '--with-ldap=shared' '--with-mysql=shared,/usr' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-apxs2=/usr/sbin/apxs' Using a standard /etc/php.ini file that works fine under PHP 4.3.6 which we upgraded to several weeks ago and this bug does not appear to be a problem with. Got the following warning (the only one) when doing a 'make': /usr/local/src/Tars/php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c: In function `convert': /usr/local/src/Tars/php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c:74: warning: passing arg 2 of `iconv' from incompatible pointer type Guessing that the call to updated versions of 'libxml' or 'libxml2' is the problem, here's the versions for both: # rpm -qi libxml Name: libxml Relocations: (not relocatable) Version: 1.8.17 Vendor: Red Hat, Inc. Release: 9.2 Build Date: Wed 17 Nov 2004 # rpm -qi libxml2 Name: libxml2Relocations: /usr Version: 2.5.10 Vendor: Red Hat, Inc. Release: 7 Build Date: Wed 27 Oct 2004 Reproduce code: --- Please use .../ext/iconv/tests/bug16069.phpt in the test suite. Expected result: The output returned does not match expected results. Actual result: -- This bug *cannot* be safely ignored as per the "Won't Fix" status in Bug #32367 because it is breaking our ability to use Japanese characters in our application with the 'mbstring' libraries. As long as we use English it's fine, but it blows up our Japanese translations (via Smarty templates.) Please do not claim it can be ignored or is a "Won't Fix" as multi-language support is becoming more and more necessary with PHP and this bug is causing major problems with it. -- Edit this bug report at http://bugs.php.net/?id=33997&edit=1
#33997 [NEW]: Returned: Bug #16069 - ICONV transliteration failure
From: RVaughn at pheedo dot com Operating system: Red Hat Ent. 3.0 PHP version: 4.4.0 PHP Bug Type: ICONV related Bug description: Returned: Bug #16069 - ICONV transliteration failure Description: In the PHP 4.4 test suite, the test for closed bug #16069 fails: FAIL Bug #16069 [ext/iconv/tests/bug16069.phpt] Checked the output and it does diverge from the expected output in the same way the old bug from 2002 did. The 'iconv' libraries are up-to-date on the system: # up2date glibc-common The following packages you requested are already updated: glibc-common # rpm -qi glibc-common Name: glibc-common Relocations: (not relocatable) Version: 2.3.2 Vendor: Red Hat, Inc. Release: 95.33 Build Date: Wed 23 Feb 2005 The bug16069.phpt script will reproduce this every time. Configured with the following settings: ./configure '--host=i386-redhat-linux' '--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-aspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--disable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos' '--with-ldap=shared' '--with-mysql=shared,/usr' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-apxs2=/usr/sbin/apxs' Using a standard /etc/php.ini file that works fine under PHP 4.3.6 which we upgraded to several weeks ago and this bug does not appear to be a problem with. Got the following warning (the only one) when doing a 'make': /usr/local/src/Tars/php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c: In function `convert': /usr/local/src/Tars/php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c:74: warning: passing arg 2 of `iconv' from incompatible pointer type Guessing that the call to updated versions of 'libxml' or 'libxml2' is the problem, here's the versions for both: # rpm -qi libxml Name: libxml Relocations: (not relocatable) Version: 1.8.17 Vendor: Red Hat, Inc. Release: 9.2 Build Date: Wed 17 Nov 2004 # rpm -qi libxml2 Name: libxml2Relocations: /usr Version: 2.5.10 Vendor: Red Hat, Inc. Release: 7 Build Date: Wed 27 Oct 2004 Reproduce code: --- Please use .../ext/iconv/tests/bug16069.phpt in the test suite. Expected result: The output returned does not match expected results. Actual result: -- This bug *cannot* be safely ignored as per the "Won't Fix" status in Bug #32367 because it is breaking our ability to use Japanese characters in our application with the 'mbstring' libraries. As long as we use English it's fine, but it blows up our Japanese translations (via Smarty templates.) Please do not claim it can be ignored or is a "Won't Fix" as multi-language support is becoming more and more necessary with PHP and this bug is causing major problems with it. -- Edit bug report at http://bugs.php.net/?id=33997&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33997&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33997&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33997&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33997&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33997&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33997&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33997&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33997&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33997&r=support Expected behavior: http://bugs.php.net/fix.php?id=33997&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33997&r=notenoughinfo Submitted twice:
#33995 [Opn]: wrong WARNING message
ID: 33995 User updated by: zxc at zmail dot ru Reported By: zxc at zmail dot ru Status: Open Bug Type: FTP related Operating System: Win2000 SP4 PHP Version: 4.4.0 New Comment: Tony, I has tried change a FTP server to something, but I show WARNING still. Previous Comments: [2005-08-04 19:56:42] zxc at zmail dot ru Example of WARNING: -- Warning: ftp_login(): Too many users - please try again later. in /pub/home/hissite/ftpconnect.php on line 73 -- Why shows a WARNING message? I use a "@" prefix before "ftp_login()" function. >>> I must have boolean FALSE only, without this WARNING. [2005-08-04 15:18:54] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. What warning? Which FTP server do you use? How to reproduce it? Are you able to reproduce it if you change your FTP server to something else? [2005-08-04 15:09:13] zxc at zmail dot ru Description: I have a WARNING message from ftp_login(), but I use a "@" with ftp_login() function. Function ftp_login() in this case must returns boolean FALSE only without WARNING. Reproduce code: --- Expected result: I have a WARNING message from ftp_login(), but I use a "@" with ftp_login() function. Function ftp_login() in this case must returns boolean FALSE only without WARNING. Actual result: -- empty screen -- Edit this bug report at http://bugs.php.net/?id=33995&edit=1
#33995 [Fbk->Opn]: wrong WARNING message
ID: 33995 User updated by: zxc at zmail dot ru Reported By: zxc at zmail dot ru -Status: Feedback +Status: Open Bug Type: FTP related Operating System: Win2000 SP4 PHP Version: 4.4.0 New Comment: Example of WARNING: -- Warning: ftp_login(): Too many users - please try again later. in /pub/home/hissite/ftpconnect.php on line 73 -- Why shows a WARNING message? I use a "@" prefix before "ftp_login()" function. >>> I must have boolean FALSE only, without this WARNING. Previous Comments: [2005-08-04 15:18:54] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. What warning? Which FTP server do you use? How to reproduce it? Are you able to reproduce it if you change your FTP server to something else? [2005-08-04 15:09:13] zxc at zmail dot ru Description: I have a WARNING message from ftp_login(), but I use a "@" with ftp_login() function. Function ftp_login() in this case must returns boolean FALSE only without WARNING. Reproduce code: --- Expected result: I have a WARNING message from ftp_login(), but I use a "@" with ftp_login() function. Function ftp_login() in this case must returns boolean FALSE only without WARNING. Actual result: -- empty screen -- Edit this bug report at http://bugs.php.net/?id=33995&edit=1
#33996 [Asn]: No information given for fatal error on passing invalid value to typed argument
ID: 33996 User updated by: phpbugs at majiclab dot com Reported By: phpbugs at majiclab dot com Status: Assigned Bug Type: Scripting Engine problem Operating System: Mac OSX 10.4 PHP Version: 5.0.4 Assigned To: dmitry New Comment: I think it's been like this for as long as I can remember using PHP, just never thought to submit a bug report for it. On a side note this should maybe be submitted as a separate bug report it would nice if these kinds of errors (invalid type, missing arguments) could throw exceptions instead of raising an error? Maybe that could even be a compile option/ phpini setting or something to keep the current behavior standard. Previous Comments: [2005-08-04 19:46:03] [EMAIL PROTECTED] Dmitry, could you plz look at it? I can reproduce it with 5.1 too. [2005-08-04 17:43:45] phpbugs at majiclab dot com Description: When passing an invalid value as a typed argument (as in ! ($argument instanceof typedclass)), a Fatal Error is given, with the following information: Fatal error: Argument 1 must be an object of class Foo in index.php on line 7 The problem is line 7 is the declaration of the function, not the line of code that called the function. It makes bug tracing on a big project next to impossible! Even using ZDE Professional has the same results: I cannot find the function that caused the error (and since the error is fatal, there is no more stack for me to look at). The same goes for missing arguments. Reproduce code: --- Expected result: Warning: Missing argument 1 for NormalTest() in /.../index.php on line 17 Hi! Warning: Argument 1 must be an object of class Foo in /.../ index.php on line 18 Actual result: -- Warning: Missing argument 1 for NormalTest() in /.../index.php on line 12 Hi! Fatal error: Argument 1 must be an object of class Foo in /.../index.php on line 7 -- Edit this bug report at http://bugs.php.net/?id=33996&edit=1
#31601 [Com]: static variable-initialisation varies depending on construction scope
ID: 31601
Comment by: bwishan at gmail dot com
Reported By: phpbugs at kaiundina dot de
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: Win XP prof/Apache 2
PHP Version: 5.0.2
New Comment:
I'm experiencing the same problem on PHP 5.0.4. Has there been any
update to this?
Previous Comments:
[2005-03-08 01:00:27] 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".
[2005-02-28 21:00:38] [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
[2005-01-19 00:19:20] phpbugs at kaiundina dot de
Description:
I have the following problem using the 'self'-operator for static
variable initialisation:
I created a class ('Item' in the reproduce code) persisting of the
following elements:
- class-constants containing key-strings
- a static variable containing an array using the above constants as
associative keys. The array was preinitialized with some values. As
nonation for the keys I used 'self::CONST_NAME' ('self::ARRAY_KEY' in
the example)
The following situations occurred:
case 1:
The first instance was created in scope of another class' constructor
('Container' in the example).
First I wondered why he was throwing a notice telling me the constant
called 'self::ARRAY_KEY' didn't exist, then I figured out that he was
searching for it in the wrong class. He tried to use the class
'Container' to initialize the static members of the 'Item' class.
Declaring the constant in the 'Container'-class again caused the
message to disappear.
case 2:
A dummy instance was created in scope of the class holding the static
member.
Now everything worked fine. The class' constructor was called from a
static method of the same class.
case 3:
I tried to directly access the static member (array) from outside any
class without having created an instance of it before.
In this case I receive a fatal error telling me "Cannot access self::
when no class scope is active"
A workaround would be to omit the self-operator when used in
static-initialisations and use the class' name instead.
another strange thing (might be a different bug - please tell me if it
is):
When the static array is filled and returned, the key's order is
different from that specified in the source. Entries having constant
keys (literally entered in the source code) appear before those
receiving their key from a class-constant. Each 'group' is ordered as
expected for itself.
let me know, if the needed information is complete.
thanks for processing
Reproduce code:
---
http://kaiundina.de/bugs/selfbug.php5.txt
(The switch block at the end of the code shows the different use cases
and their respective output)
Expected result:
The static members should be initialized using the constants as
declared in the own class rather than using constants declared in the
scope of the script that creates the first instance of the class.
In other words:
The 'self' operator should always refer to the class in which it
appears when used for initialisation of static members.
Actual result:
--
The 'self'-operator, when used for initialisation of static members,
refers to the class (if present) that executes the first
'new'-statement for the class containing the static member.
--
Edit this bug report at http://bugs.php.net/?id=31601&edit=1
#33996 [Opn->Asn]: No information given for fatal error on passing invalid value to typed argument
ID: 33996 Updated by: [EMAIL PROTECTED] Reported By: phpbugs at majiclab dot com -Status: Open +Status: Assigned Bug Type: Scripting Engine problem Operating System: Mac OSX 10.4 PHP Version: 5.0.4 -Assigned To: +Assigned To: dmitry New Comment: Dmitry, could you plz look at it? I can reproduce it with 5.1 too. Previous Comments: [2005-08-04 17:43:45] phpbugs at majiclab dot com Description: When passing an invalid value as a typed argument (as in ! ($argument instanceof typedclass)), a Fatal Error is given, with the following information: Fatal error: Argument 1 must be an object of class Foo in index.php on line 7 The problem is line 7 is the declaration of the function, not the line of code that called the function. It makes bug tracing on a big project next to impossible! Even using ZDE Professional has the same results: I cannot find the function that caused the error (and since the error is fatal, there is no more stack for me to look at). The same goes for missing arguments. Reproduce code: --- Expected result: Warning: Missing argument 1 for NormalTest() in /.../index.php on line 17 Hi! Warning: Argument 1 must be an object of class Foo in /.../ index.php on line 18 Actual result: -- Warning: Missing argument 1 for NormalTest() in /.../index.php on line 12 Hi! Fatal error: Argument 1 must be an object of class Foo in /.../index.php on line 7 -- Edit this bug report at http://bugs.php.net/?id=33996&edit=1
#33991 [Fbk->Opn]: Bug test #25665 fails on Solaris
ID: 33991 User updated by: akim at freedom dot com Reported By: akim at freedom dot com -Status: Feedback +Status: Open Bug Type: Math related Operating System: Solaris 2.9 / SPARC PHP Version: 5.0.4 New Comment: Same results with latest snapshot. Previous Comments: [2005-08-04 08:43:08] [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 [2005-08-04 02:19:08] akim at freedom dot com Description: acos() function returns "0" rather than "NAN" for values of |x| > 1. Among other things this causes test ext/standard/tests/math/bug25665.phpt to fail. This may be caused by ambiguous handling of out-of-range arguments in the Solaris implementation of acos(). From the acos() man page: "If the value of x is not in the range [-1,1], and is not +-Inf or NaN, either 0.0 or NaN is returned and errno is set to EDOM." Configure line: ./configure --with-apxs=/www/apache/bin/apxs --with-mssql=/www/freetds063 --enable-ftp Dependencies: libsybdb.so.5 => /www/freetds063/lib/libsybdb.so.5 libnsl.so.1 => /lib/libnsl.so.1 libsocket.so.1 =>/lib/libsocket.so.1 libc.so.1 => /lib/libc.so.1 libresolv.so.2 =>/lib/libresolv.so.2 libm.so.1 => /lib/libm.so.1 libdl.so.1 =>/lib/libdl.so.1 libz.so.1 => /lib/libz.so.1 libxml2.so.2 => /usr/local/lib/libxml2.so.2 libpthread.so.1 => /lib/libpthread.so.1 libiconv.so.2 => /usr/local/lib/libiconv.so.2 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libmp.so.2 =>/lib/libmp.so.2 /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1 libthread.so.1 =>/lib/libthread.so.1 librt.so.1 =>/lib/librt.so.1 libaio.so.1 => /lib/libaio.so.1 libmd5.so.1 => /lib/libmd5.so.1 /usr/platform/SUNW,UltraAX-i2/lib/libmd5_psr.so.1 gcc -v output: Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.4.2 Reproduce code: --- Expected result: float(NAN) float(-INF) Actual result: -- float(0) float(-INF) -- Edit this bug report at http://bugs.php.net/?id=33991&edit=1
#33987 [Fbk->Opn]: .php file in ErrorDocument causes apache crash
ID: 33987 User updated by: php dot net at sharpdreams dot com Reported By: php dot net at sharpdreams dot com -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Win32 (XP SP2) PHP Version: 5CVS-2005-08-03 New Comment: There is no entry in either error_log or access_log (I presume it crashes before logging). If I turn on the rewriting log, I can see the request getting rewritten until it hits /error.php. I know it crashes because it pops u the Visual Studio debuger. Previous Comments: [2005-08-04 09:11:07] [EMAIL PROTECTED] What do you get in the apache error_log when this problem happens? Are you sure it really crashes..? [2005-08-04 01:37:03] php dot net at sharpdreams dot com LoadModule php5_module "C:/www/apache2/PHP5-1/php5apache2.dll" AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps PHPIniDir "C:/www/apache2/php5-1" [2005-08-03 22:47:58] [EMAIL PROTECTED] How have you enabled PHP in the httpd.conf file? (what lines did you add there to enable it..) [2005-08-03 22:17:11] php dot net at sharpdreams dot com This only seems to happen in Win32, works fine under our BSD boxes. Windows XP SP2, Apache 2/2.0.54, PHP 5.1.0-dev (built: Aug 3 2005 20:36:22). Changing my error document to anything other than a PHP file works (e.g., ErrorDocument error.html or /cgi-bin/error.pl). [2005-08-03 22:02:52] php dot net at sharpdreams dot com Tested on 5.0.3 release and it works fine. Some kind of regression between 5.0.3 and 5.1CVS. 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/33987 -- Edit this bug report at http://bugs.php.net/?id=33987&edit=1
#33994 [WFx]: DB unavailable after forked child exits
ID: 33994
User updated by: greatwhitepine at bigfoot dot com
Reported By: greatwhitepine at bigfoot dot com
Status: Wont fix
Bug Type: Ingres II related
Operating System: Tru64 UNIX V5.1B (Rev. 2650)
PHP Version: 5.0.4
New Comment:
Seperate connections does not work (as per the example)!
Previous Comments:
[2005-08-04 08:45:38] [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
Use separate connections or something else than ingres (moved to PECL,
report bugs on it to pecl.php.net/bugs..)
[2005-08-04 08:14:13] greatwhitepine at bigfoot dot com
Sorry, forgot the pcntl_waitpid during my 1st edit (see below).
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from auto_ldg_run')) {
print 'db ok during fork'."\n\n";
}
$int_pid = pcntl_fork();
if(!$int_pid) {
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from auto_ldg_run')) {
print 'db ok for child'."\n\n";
}
exit();
}
pcntl_waitpid ($int_pid, $str_status);
ingres_connect($str_database, $str_username, $str_password);
if (!ingres_query('select count(*) from auto_ldg_run')) {
print 'db not ok after fork'."\n\n";
}
exit(1);
[2005-08-04 08:03:06] greatwhitepine at bigfoot dot com
Description:
As per the manual ingres_connect connections are terminated when the
process exits. When a forked child exits the connection is terminated
permanently until the parent process is restarted.
Reproduce code:
---
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from table')) {
print 'db ok during fork'."\n\n";
}
$int_pid = pcntl_fork();
if(!$int_pid) {
ingres_connect($str_database, $str_username, $str_password);
if (ingres_query('select count(*) from table')) {
print 'db ok for child'."\n\n";
}
exit();
}
ingres_connect($str_database, $str_username, $str_password);
if (!ingres_query('select count(*) from table')) {
print 'db not ok after fork'."\n\n";
}
Expected result:
db ok during fork
db ok for child
Actual result:
--
db ok during fork
db ok for child
Warning: ingres_query(): Ingres II: Server or API error : Read from
peer process failed; it may have exited. in
/home/its/autoldg/lib/php/local/lib_autoldg_daemon.php on line 228
Warning: ingres_query(): Ingres II: SQLSTATE : 08004 in
/home/its/autoldg/lib/php/local/lib_autoldg_daemon.php on line 228
db not ok after fork
Warning: Unknown: Ingres II: Server or API error : API function cannot
be called in the current state. in Unknown on line 0
Warning: Unknown: Ingres II: SQLSTATE : 5000R in Unknown on line 0
Warning: Unknown: Ingres II: Unable to close statement !! in Unknown
on line 0
Warning: Unknown: Ingres II: Unable to rollback transaction !! in
Unknown on line 0
--
Edit this bug report at http://bugs.php.net/?id=33994&edit=1
#33996 [NEW]: No information given for fatal error on passing invalid value to typed argument
From: phpbugs at majiclab dot com Operating system: Mac OSX 10.4 PHP version: 5.0.4 PHP Bug Type: Scripting Engine problem Bug description: No information given for fatal error on passing invalid value to typed argument Description: When passing an invalid value as a typed argument (as in ! ($argument instanceof typedclass)), a Fatal Error is given, with the following information: Fatal error: Argument 1 must be an object of class Foo in index.php on line 7 The problem is line 7 is the declaration of the function, not the line of code that called the function. It makes bug tracing on a big project next to impossible! Even using ZDE Professional has the same results: I cannot find the function that caused the error (and since the error is fatal, there is no more stack for me to look at). The same goes for missing arguments. Reproduce code: --- Expected result: Warning: Missing argument 1 for NormalTest() in /.../index.php on line 17 Hi! Warning: Argument 1 must be an object of class Foo in /.../ index.php on line 18 Actual result: -- Warning: Missing argument 1 for NormalTest() in /.../index.php on line 12 Hi! Fatal error: Argument 1 must be an object of class Foo in /.../index.php on line 7 -- Edit bug report at http://bugs.php.net/?id=33996&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33996&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33996&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33996&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33996&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33996&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33996&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33996&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33996&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33996&r=support Expected behavior: http://bugs.php.net/fix.php?id=33996&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33996&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33996&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33996&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33996&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33996&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33996&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33996&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33996&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33996&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33996&r=mysqlcfg
#33871 [Asn]: No daylight savings time
ID: 33871
User updated by: jeremy at techtrav dot com
Reported By: jeremy at techtrav dot com
Status: Assigned
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
Assigned To: derick
New Comment:
By the way I do have E_ALL turned on, on my machine. After all I don't
run my windows box with PHP in production. I use my windows box for
development. Our PHP production runs on OpenBSD servers.
I don't quite understand this comment of yours:
"Now, if we can find a way how PHP can guess the correct timezone from
your windows box "
PHP 5.0.4 reads my TZ perfectly and gives you the expected result. Why
would PHP 5.1.X not be able to?
Previous Comments:
[2005-08-04 16:55:55] jeremy at techtrav dot com
okay I figured out how to set my time zone.
I ran the following code in PHP 5.0.4 and PHP 5.1.X and recieved the
same result
putenv("TZ=US/Central");
echo date('r', (strtotime('oct 25')+(86400*6)));
This would mean the bug is simply that PHP5.1.X is not looking at the
time zone on the local machine.
[2005-08-04 16:54:58] [EMAIL PROTECTED]
That function is only there in the snapshots, please try that instead.
http://snaps.php.net (and pick latest cvs (5.1-dev) there).
[2005-08-04 16:53:03] [EMAIL PROTECTED]
Now, if we can find a way how PHP can guess the correct timezone from
your windows box (like it can do on most unices) that would be nice -
but I think it's quite impossible.
BTW, if you use error_reporting(E_ALL) you'd have gotten a warning
about this...
[2005-08-04 16:51:34] jeremy at techtrav dot com
I tried adding that line to the top of my code. I am not familar with
that function nor do I find it in the documentation. I get a fatal
error:
Fatal error: Call to undefined function date_default_timezone_set()
when I run this script:
date_default_timezone_set("America/New_York");
echo date('r', (strtotime('oct 25')+(86400*6)));
I would agree with you in your conclusion though that it would appear
that PHP 5.1.X is not reading the timezone of the local machine.
[2005-08-04 16:44:09] jeremy at techtrav dot com
Oh now I understand Czimi comment. If PHP 5.1.X is not looking at the
time zone on my XP box then it is not going to know that Oct 30th is
daylight savings time. I think Czimi is probably right, PHP 5.1.X is
not looking at the time zone my my XP box.
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/33871
--
Edit this bug report at http://bugs.php.net/?id=33871&edit=1
#33871 [Asn]: No daylight savings time
ID: 33871
User updated by: jeremy at techtrav dot com
Reported By: jeremy at techtrav dot com
Status: Assigned
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
Assigned To: derick
New Comment:
okay I figured out how to set my time zone.
I ran the following code in PHP 5.0.4 and PHP 5.1.X and recieved the
same result
putenv("TZ=US/Central");
echo date('r', (strtotime('oct 25')+(86400*6)));
This would mean the bug is simply that PHP5.1.X is not looking at the
time zone on the local machine.
Previous Comments:
[2005-08-04 16:54:58] [EMAIL PROTECTED]
That function is only there in the snapshots, please try that instead.
http://snaps.php.net (and pick latest cvs (5.1-dev) there).
[2005-08-04 16:53:03] [EMAIL PROTECTED]
Now, if we can find a way how PHP can guess the correct timezone from
your windows box (like it can do on most unices) that would be nice -
but I think it's quite impossible.
BTW, if you use error_reporting(E_ALL) you'd have gotten a warning
about this...
[2005-08-04 16:51:34] jeremy at techtrav dot com
I tried adding that line to the top of my code. I am not familar with
that function nor do I find it in the documentation. I get a fatal
error:
Fatal error: Call to undefined function date_default_timezone_set()
when I run this script:
date_default_timezone_set("America/New_York");
echo date('r', (strtotime('oct 25')+(86400*6)));
I would agree with you in your conclusion though that it would appear
that PHP 5.1.X is not reading the timezone of the local machine.
[2005-08-04 16:44:09] jeremy at techtrav dot com
Oh now I understand Czimi comment. If PHP 5.1.X is not looking at the
time zone on my XP box then it is not going to know that Oct 30th is
daylight savings time. I think Czimi is probably right, PHP 5.1.X is
not looking at the time zone my my XP box.
[2005-08-04 16:43:09] [EMAIL PROTECTED]
Look at the formatted date:
Mon, 31 Oct 2005 00:00:00 +
It doesn't have a timezone offset, so it seems that "xczimi" is right.
Does it help if you add:
date_default_timezone_set("America/New_York") at the top of the script?
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/33871
--
Edit this bug report at http://bugs.php.net/?id=33871&edit=1
#33871 [Asn]: No daylight savings time
ID: 33871
Updated by: [EMAIL PROTECTED]
Reported By: jeremy at techtrav dot com
Status: Assigned
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
Assigned To: derick
New Comment:
That function is only there in the snapshots, please try that instead.
http://snaps.php.net (and pick latest cvs (5.1-dev) there).
Previous Comments:
[2005-08-04 16:53:03] [EMAIL PROTECTED]
Now, if we can find a way how PHP can guess the correct timezone from
your windows box (like it can do on most unices) that would be nice -
but I think it's quite impossible.
BTW, if you use error_reporting(E_ALL) you'd have gotten a warning
about this...
[2005-08-04 16:51:34] jeremy at techtrav dot com
I tried adding that line to the top of my code. I am not familar with
that function nor do I find it in the documentation. I get a fatal
error:
Fatal error: Call to undefined function date_default_timezone_set()
when I run this script:
date_default_timezone_set("America/New_York");
echo date('r', (strtotime('oct 25')+(86400*6)));
I would agree with you in your conclusion though that it would appear
that PHP 5.1.X is not reading the timezone of the local machine.
[2005-08-04 16:44:09] jeremy at techtrav dot com
Oh now I understand Czimi comment. If PHP 5.1.X is not looking at the
time zone on my XP box then it is not going to know that Oct 30th is
daylight savings time. I think Czimi is probably right, PHP 5.1.X is
not looking at the time zone my my XP box.
[2005-08-04 16:43:09] [EMAIL PROTECTED]
Look at the formatted date:
Mon, 31 Oct 2005 00:00:00 +
It doesn't have a timezone offset, so it seems that "xczimi" is right.
Does it help if you add:
date_default_timezone_set("America/New_York") at the top of the script?
[2005-08-04 16:32:54] jeremy at techtrav dot com
well the problem comes when you cross the daylight savings time day of
Oct 30th. Strtotime will handle the 25 hour day just great.
Remebering there are 25 hours in Oct 30th is important. That is why
when you run the following code in PHP 5.0.4
echo date('r', (strtotime('oct 25')+(86400*6)));
you do get (which is right):
Sun, 30 Oct 2005 23:00:00 -0600
an hour short of Oct 31st. However when you run that code in PHP 5.1.X
you find that Oct 30th does not contain 25 hours.
Mon, 31 Oct 2005 00:00:00 +
This difference will definitely screw up scripts that are particularly
time sensitive, like my field of Travel.
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/33871
--
Edit this bug report at http://bugs.php.net/?id=33871&edit=1
#33871 [Asn]: No daylight savings time
ID: 33871
Updated by: [EMAIL PROTECTED]
Reported By: jeremy at techtrav dot com
Status: Assigned
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
Assigned To: derick
New Comment:
Now, if we can find a way how PHP can guess the correct timezone from
your windows box (like it can do on most unices) that would be nice -
but I think it's quite impossible.
BTW, if you use error_reporting(E_ALL) you'd have gotten a warning
about this...
Previous Comments:
[2005-08-04 16:51:34] jeremy at techtrav dot com
I tried adding that line to the top of my code. I am not familar with
that function nor do I find it in the documentation. I get a fatal
error:
Fatal error: Call to undefined function date_default_timezone_set()
when I run this script:
date_default_timezone_set("America/New_York");
echo date('r', (strtotime('oct 25')+(86400*6)));
I would agree with you in your conclusion though that it would appear
that PHP 5.1.X is not reading the timezone of the local machine.
[2005-08-04 16:44:09] jeremy at techtrav dot com
Oh now I understand Czimi comment. If PHP 5.1.X is not looking at the
time zone on my XP box then it is not going to know that Oct 30th is
daylight savings time. I think Czimi is probably right, PHP 5.1.X is
not looking at the time zone my my XP box.
[2005-08-04 16:43:09] [EMAIL PROTECTED]
Look at the formatted date:
Mon, 31 Oct 2005 00:00:00 +
It doesn't have a timezone offset, so it seems that "xczimi" is right.
Does it help if you add:
date_default_timezone_set("America/New_York") at the top of the script?
[2005-08-04 16:32:54] jeremy at techtrav dot com
well the problem comes when you cross the daylight savings time day of
Oct 30th. Strtotime will handle the 25 hour day just great.
Remebering there are 25 hours in Oct 30th is important. That is why
when you run the following code in PHP 5.0.4
echo date('r', (strtotime('oct 25')+(86400*6)));
you do get (which is right):
Sun, 30 Oct 2005 23:00:00 -0600
an hour short of Oct 31st. However when you run that code in PHP 5.1.X
you find that Oct 30th does not contain 25 hours.
Mon, 31 Oct 2005 00:00:00 +
This difference will definitely screw up scripts that are particularly
time sensitive, like my field of Travel.
[2005-08-04 10:11:37] xczimi at sztaki dot hu
I unpacked both 5.0.4, 5.1.0b3 and the latest code to my Win XP box,
and tried the following in command line:
C:\devtool>php-5.1.0b3\php -r "echo date('r');"
Thu, 04 Aug 2005 08:05:40 +
C:\devtool>php-5.0.4\php -r "echo date('r');"
Thu, 04 Aug 2005 10:05:45 +0200
C:\devtool>php-latest\php -r "echo date('r');"
Thu, 04 Aug 2005 08:10:33 +
I think the oly problem is that php doesn't read the timezone of the
Operating system.
regards,
Czimi
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/33871
--
Edit this bug report at http://bugs.php.net/?id=33871&edit=1
#33871 [Asn]: No daylight savings time
ID: 33871
User updated by: jeremy at techtrav dot com
Reported By: jeremy at techtrav dot com
Status: Assigned
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
Assigned To: derick
New Comment:
I tried adding that line to the top of my code. I am not familar with
that function nor do I find it in the documentation. I get a fatal
error:
Fatal error: Call to undefined function date_default_timezone_set()
when I run this script:
date_default_timezone_set("America/New_York");
echo date('r', (strtotime('oct 25')+(86400*6)));
I would agree with you in your conclusion though that it would appear
that PHP 5.1.X is not reading the timezone of the local machine.
Previous Comments:
[2005-08-04 16:44:09] jeremy at techtrav dot com
Oh now I understand Czimi comment. If PHP 5.1.X is not looking at the
time zone on my XP box then it is not going to know that Oct 30th is
daylight savings time. I think Czimi is probably right, PHP 5.1.X is
not looking at the time zone my my XP box.
[2005-08-04 16:43:09] [EMAIL PROTECTED]
Look at the formatted date:
Mon, 31 Oct 2005 00:00:00 +
It doesn't have a timezone offset, so it seems that "xczimi" is right.
Does it help if you add:
date_default_timezone_set("America/New_York") at the top of the script?
[2005-08-04 16:32:54] jeremy at techtrav dot com
well the problem comes when you cross the daylight savings time day of
Oct 30th. Strtotime will handle the 25 hour day just great.
Remebering there are 25 hours in Oct 30th is important. That is why
when you run the following code in PHP 5.0.4
echo date('r', (strtotime('oct 25')+(86400*6)));
you do get (which is right):
Sun, 30 Oct 2005 23:00:00 -0600
an hour short of Oct 31st. However when you run that code in PHP 5.1.X
you find that Oct 30th does not contain 25 hours.
Mon, 31 Oct 2005 00:00:00 +
This difference will definitely screw up scripts that are particularly
time sensitive, like my field of Travel.
[2005-08-04 10:11:37] xczimi at sztaki dot hu
I unpacked both 5.0.4, 5.1.0b3 and the latest code to my Win XP box,
and tried the following in command line:
C:\devtool>php-5.1.0b3\php -r "echo date('r');"
Thu, 04 Aug 2005 08:05:40 +
C:\devtool>php-5.0.4\php -r "echo date('r');"
Thu, 04 Aug 2005 10:05:45 +0200
C:\devtool>php-latest\php -r "echo date('r');"
Thu, 04 Aug 2005 08:10:33 +
I think the oly problem is that php doesn't read the timezone of the
Operating system.
regards,
Czimi
[2005-07-26 18:21:13] jeremy at techtrav dot com
I am Central Standard Time in MN and we are on Day light Savings time.
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/33871
--
Edit this bug report at http://bugs.php.net/?id=33871&edit=1
#33871 [Asn]: No daylight savings time
ID: 33871
User updated by: jeremy at techtrav dot com
Reported By: jeremy at techtrav dot com
Status: Assigned
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
Assigned To: derick
New Comment:
Oh now I understand Czimi comment. If PHP 5.1.X is not looking at the
time zone on my XP box then it is not going to know that Oct 30th is
daylight savings time. I think Czimi is probably right, PHP 5.1.X is
not looking at the time zone my my XP box.
Previous Comments:
[2005-08-04 16:43:09] [EMAIL PROTECTED]
Look at the formatted date:
Mon, 31 Oct 2005 00:00:00 +
It doesn't have a timezone offset, so it seems that "xczimi" is right.
Does it help if you add:
date_default_timezone_set("America/New_York") at the top of the script?
[2005-08-04 16:32:54] jeremy at techtrav dot com
well the problem comes when you cross the daylight savings time day of
Oct 30th. Strtotime will handle the 25 hour day just great.
Remebering there are 25 hours in Oct 30th is important. That is why
when you run the following code in PHP 5.0.4
echo date('r', (strtotime('oct 25')+(86400*6)));
you do get (which is right):
Sun, 30 Oct 2005 23:00:00 -0600
an hour short of Oct 31st. However when you run that code in PHP 5.1.X
you find that Oct 30th does not contain 25 hours.
Mon, 31 Oct 2005 00:00:00 +
This difference will definitely screw up scripts that are particularly
time sensitive, like my field of Travel.
[2005-08-04 10:11:37] xczimi at sztaki dot hu
I unpacked both 5.0.4, 5.1.0b3 and the latest code to my Win XP box,
and tried the following in command line:
C:\devtool>php-5.1.0b3\php -r "echo date('r');"
Thu, 04 Aug 2005 08:05:40 +
C:\devtool>php-5.0.4\php -r "echo date('r');"
Thu, 04 Aug 2005 10:05:45 +0200
C:\devtool>php-latest\php -r "echo date('r');"
Thu, 04 Aug 2005 08:10:33 +
I think the oly problem is that php doesn't read the timezone of the
Operating system.
regards,
Czimi
[2005-07-26 18:21:13] jeremy at techtrav dot com
I am Central Standard Time in MN and we are on Day light Savings time.
[2005-07-26 18:16:49] [EMAIL PROTECTED]
This could be also a timezone issue.
What's your TZ ?
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/33871
--
Edit this bug report at http://bugs.php.net/?id=33871&edit=1
#33871 [Asn]: No daylight savings time
ID: 33871
Updated by: [EMAIL PROTECTED]
Reported By: jeremy at techtrav dot com
Status: Assigned
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
Assigned To: derick
New Comment:
Look at the formatted date:
Mon, 31 Oct 2005 00:00:00 +
It doesn't have a timezone offset, so it seems that "xczimi" is right.
Does it help if you add:
date_default_timezone_set("America/New_York") at the top of the script?
Previous Comments:
[2005-08-04 16:32:54] jeremy at techtrav dot com
well the problem comes when you cross the daylight savings time day of
Oct 30th. Strtotime will handle the 25 hour day just great.
Remebering there are 25 hours in Oct 30th is important. That is why
when you run the following code in PHP 5.0.4
echo date('r', (strtotime('oct 25')+(86400*6)));
you do get (which is right):
Sun, 30 Oct 2005 23:00:00 -0600
an hour short of Oct 31st. However when you run that code in PHP 5.1.X
you find that Oct 30th does not contain 25 hours.
Mon, 31 Oct 2005 00:00:00 +
This difference will definitely screw up scripts that are particularly
time sensitive, like my field of Travel.
[2005-08-04 10:11:37] xczimi at sztaki dot hu
I unpacked both 5.0.4, 5.1.0b3 and the latest code to my Win XP box,
and tried the following in command line:
C:\devtool>php-5.1.0b3\php -r "echo date('r');"
Thu, 04 Aug 2005 08:05:40 +
C:\devtool>php-5.0.4\php -r "echo date('r');"
Thu, 04 Aug 2005 10:05:45 +0200
C:\devtool>php-latest\php -r "echo date('r');"
Thu, 04 Aug 2005 08:10:33 +
I think the oly problem is that php doesn't read the timezone of the
Operating system.
regards,
Czimi
[2005-07-26 18:21:13] jeremy at techtrav dot com
I am Central Standard Time in MN and we are on Day light Savings time.
[2005-07-26 18:16:49] [EMAIL PROTECTED]
This could be also a timezone issue.
What's your TZ ?
[2005-07-26 18:12:59] jeremy at techtrav dot com
I have upgraded to the newest snap as you have requested and I am still
getting the same results. PHP 5.0.4 returns the correct time. PHP
5.1.X returns the wrong time. Could this be an operating system issue?
I am on Windows XP with Apache 2.
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/33871
--
Edit this bug report at http://bugs.php.net/?id=33871&edit=1
#33871 [Asn]: No daylight savings time
ID: 33871
User updated by: jeremy at techtrav dot com
Reported By: jeremy at techtrav dot com
Status: Assigned
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
Assigned To: derick
New Comment:
well the problem comes when you cross the daylight savings time day of
Oct 30th. Strtotime will handle the 25 hour day just great.
Remebering there are 25 hours in Oct 30th is important. That is why
when you run the following code in PHP 5.0.4
echo date('r', (strtotime('oct 25')+(86400*6)));
you do get (which is right):
Sun, 30 Oct 2005 23:00:00 -0600
an hour short of Oct 31st. However when you run that code in PHP 5.1.X
you find that Oct 30th does not contain 25 hours.
Mon, 31 Oct 2005 00:00:00 +
This difference will definitely screw up scripts that are particularly
time sensitive, like my field of Travel.
Previous Comments:
[2005-08-04 10:11:37] xczimi at sztaki dot hu
I unpacked both 5.0.4, 5.1.0b3 and the latest code to my Win XP box,
and tried the following in command line:
C:\devtool>php-5.1.0b3\php -r "echo date('r');"
Thu, 04 Aug 2005 08:05:40 +
C:\devtool>php-5.0.4\php -r "echo date('r');"
Thu, 04 Aug 2005 10:05:45 +0200
C:\devtool>php-latest\php -r "echo date('r');"
Thu, 04 Aug 2005 08:10:33 +
I think the oly problem is that php doesn't read the timezone of the
Operating system.
regards,
Czimi
[2005-07-26 18:21:13] jeremy at techtrav dot com
I am Central Standard Time in MN and we are on Day light Savings time.
[2005-07-26 18:16:49] [EMAIL PROTECTED]
This could be also a timezone issue.
What's your TZ ?
[2005-07-26 18:12:59] jeremy at techtrav dot com
I have upgraded to the newest snap as you have requested and I am still
getting the same results. PHP 5.0.4 returns the correct time. PHP
5.1.X returns the wrong time. Could this be an operating system issue?
I am on Windows XP with Apache 2.
[2005-07-26 18:05: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
>you get the expected result:
No, *I* get the expected result with both versions.
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/33871
--
Edit this bug report at http://bugs.php.net/?id=33871&edit=1
#33995 [Opn->Fbk]: wrong WARNING message
ID: 33995 Updated by: [EMAIL PROTECTED] Reported By: zxc at zmail dot ru -Status: Open +Status: Feedback Bug Type: FTP related Operating System: Win2000 SP4 PHP Version: 4.4.0 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. What warning? Which FTP server do you use? How to reproduce it? Are you able to reproduce it if you change your FTP server to something else? Previous Comments: [2005-08-04 15:09:13] zxc at zmail dot ru Description: I have a WARNING message from ftp_login(), but I use a "@" with ftp_login() function. Function ftp_login() in this case must returns boolean FALSE only without WARNING. Reproduce code: --- Expected result: I have a WARNING message from ftp_login(), but I use a "@" with ftp_login() function. Function ftp_login() in this case must returns boolean FALSE only without WARNING. Actual result: -- empty screen -- Edit this bug report at http://bugs.php.net/?id=33995&edit=1
#33995 [NEW]: wrong WARNING message
From: zxc at zmail dot ru Operating system: Win2000 SP4 PHP version: 4.4.0 PHP Bug Type: Unknown/Other Function Bug description: wrong WARNING message Description: I have a WARNING message from ftp_login(), but I use a "@" with ftp_login() function. Function ftp_login() in this case must returns boolean FALSE only without WARNING. Reproduce code: --- Expected result: I have a WARNING message from ftp_login(), but I use a "@" with ftp_login() function. Function ftp_login() in this case must returns boolean FALSE only without WARNING. Actual result: -- empty screen -- Edit bug report at http://bugs.php.net/?id=33995&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33995&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33995&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33995&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33995&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33995&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33995&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33995&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33995&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33995&r=support Expected behavior: http://bugs.php.net/fix.php?id=33995&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33995&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33995&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33995&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33995&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33995&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33995&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33995&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33995&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33995&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33995&r=mysqlcfg
#33974 [Bgs]: ob_list_handlers(): object-based handlers returned incorrectly.
ID: 33974
User updated by: php at koterov dot ru
Reported By: php at koterov dot ru
Status: Bogus
Bug Type: Output Control
Operating System: any
PHP Version: 4.3.11
New Comment:
I'll detalize why do I say all this words. It would be great to
MANUALLY process all output buffers with their callbacks at the end of
script - something like this:
foreach (array_reverse(ob_list_handlers()) as $h) {
$text = ob_get_contents(); ob_end_clean();
echo call_user_func($h, $text);
}
Why? Very simple: if I let the callbacks to be called automatically,
I'll loose ALL errors, warnings and notices in them, because errors are
suppress on standard OB callback execution. But, if I call all the
callbacks manually (see example above), it's OK with errors.
I use OB callbacks very often, an there are a lot of PHP code in them
(e.g. - HTML tag parsing, placeholder substitutions etc.). Callbacks is
a very powerful technique, but - almost undebuggable.
Maybe extend ob_get_status(true) adding valid callback references to
returned array?
Previous Comments:
[2005-08-04 13:49:15] php at koterov dot ru
Very strange, because object-based callbacks works fine with
ob_start(). So I guess that full callback info is stored somewhere.
OK, debug purpose. But - maybe write it explicitly in documentation?
"This function is for debug purposes only. Do not try to use it for
manual callback execution - references will be wrong for object-based
callbacks."
[2005-08-03 15:46:05] [EMAIL PROTECTED]
This is how the engine stores callbacks names.
ob_list_handlers() has nothing to do with it.
This functions is for debugging purposes only and there is nothing said
in the docs that it should return valid callbacks.
[2005-08-03 15:35:21] php at koterov dot ru
There is nothing said about this behaviour in the documentation:
http://www.php.net/manual/ru/function.ob-list-handlers.php
And - if I cannot trust the result of ob_list_handlers() (I cannot - it
returns bogus handler names), is this function necessary at all?
[2005-08-03 13:22:51] [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
[2005-08-03 12:35:45] php at koterov dot ru
Description:
Seems ob_list_handlers() cannot return handlers represented as object
with method names (see ob_start(array(&$obj, 'F'))). It returns them as
"ClassName::MethodName", not as array(..., ...).
Reproduce code:
---
Expected result:
array(1) { [0]=> array(..., 'F') }
// where "..." is object $obj
Actual result:
--
array(1) { [0]=> string(4) "c::F" }
--
Edit this bug report at http://bugs.php.net/?id=33974&edit=1
#33974 [Bgs]: ob_list_handlers(): object-based handlers returned incorrectly.
ID: 33974
User updated by: php at koterov dot ru
Reported By: php at koterov dot ru
Status: Bogus
Bug Type: Output Control
Operating System: any
PHP Version: 4.3.11
New Comment:
Very strange, because object-based callbacks works fine with
ob_start(). So I guess that full callback info is stored somewhere.
OK, debug purpose. But - maybe write it explicitly in documentation?
"This function is for debug purposes only. Do not try to use it for
manual callback execution - references will be wrong for object-based
callbacks."
Previous Comments:
[2005-08-03 15:46:05] [EMAIL PROTECTED]
This is how the engine stores callbacks names.
ob_list_handlers() has nothing to do with it.
This functions is for debugging purposes only and there is nothing said
in the docs that it should return valid callbacks.
[2005-08-03 15:35:21] php at koterov dot ru
There is nothing said about this behaviour in the documentation:
http://www.php.net/manual/ru/function.ob-list-handlers.php
And - if I cannot trust the result of ob_list_handlers() (I cannot - it
returns bogus handler names), is this function necessary at all?
[2005-08-03 13:22:51] [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
[2005-08-03 12:35:45] php at koterov dot ru
Description:
Seems ob_list_handlers() cannot return handlers represented as object
with method names (see ob_start(array(&$obj, 'F'))). It returns them as
"ClassName::MethodName", not as array(..., ...).
Reproduce code:
---
Expected result:
array(1) { [0]=> array(..., 'F') }
// where "..." is object $obj
Actual result:
--
array(1) { [0]=> string(4) "c::F" }
--
Edit this bug report at http://bugs.php.net/?id=33974&edit=1
#30519 [Csd]: Interface not existing says Class not found
ID: 30519 Updated by: [EMAIL PROTECTED] Reported By: jsgoupil at lookstrike dot com Status: Closed Bug Type: Scripting Engine problem Operating System: * PHP Version: 5CVS-2005-06-19 Assigned To: dmitry New Comment: Sorry, I saw PHP_5_0, I was thinking that PHP_5_1 was existing... or something like that. Previous Comments: [2005-08-04 09:14:01] [EMAIL PROTECTED] Works as expected with latest CVS snapshot. DO NOT REOPEN BUGS if you HAVE NOT tested with LATEST CVS [2005-08-04 06:10:00] [EMAIL PROTECTED] Reproducible in 5.1.0b2 [2005-06-24 10:46:14] [EMAIL PROTECTED] Fixed in CVS HEAD and PHP_5_0. [2004-10-21 20:48:56] jsgoupil at lookstrike dot com Description: If you specify an interface that not exists to a class, the output error is saying a "wrong" message... Reproduce code: --- Expected result: Fatal error: Interface 'a' not found in D:\www\LookStrike\ls_lite\a.php on line 2 Actual result: -- Fatal error: Class 'a' not found in D:\www\LookStrike\ls_lite\a.php on line 2 -- Edit this bug report at http://bugs.php.net/?id=30519&edit=1
#33983 [Bgs]: bugy result from get_all_tokens()
ID: 33983
User updated by: smart at open-publisher dot net
Reported By: smart at open-publisher dot net
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: XP
PHP Version: 5.0.4
New Comment:
Thanks for the lovely tip ... RTFM.
The problem is that the content of this array that the function
get_all_tokens() return throw php in nirvana. Server message: "Document
contains no data". It toke hours to find out that this bug is
undebugable just by analyzing code line by line. A simple class methode
which is correctly executed until the last bracked hangs.
class test
{
}
It's definetely a php internal error.
Previous Comments:
[2005-08-03 22:20:55] [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's inline HTML..RTFM..
[2005-08-03 19:30:47] smart at open-publisher dot net
You can see that the array $tokens contains html fragments
";var_dump($tokens);echo "";
?>
snip - test.php file to parse --
SMART3 -
end snip - test.php file to parse --
[2005-08-03 18:14:59] smart at open-publisher dot net
Description:
When parsing files that contains mixed html + php code with the
function get_all_tokens() the returned array contains a lot of html
fragments. Also when parsing some files the returned array cause heavy
problems. The Server return "document contains no data". But the same
file is correctly parsed by the php interpreter. So i think the problem
is the function get_all_tokens().
--
Edit this bug report at http://bugs.php.net/?id=33983&edit=1
#33989 [Ver->Csd]: extract()/eval()/require() crashes php
ID: 33989
Updated by: [EMAIL PROTECTED]
Reported By: mdpm2 at rohms dot com
-Status: Verified
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5CVS, 4CVS (2005-08-03)
New Comment:
Fixed in CVS HEAD, PHP_5_0 and PHP_4_4.
Previous Comments:
[2005-08-04 00:12:01] [EMAIL PROTECTED]
is enough to see errors when Zend MM is disabled (with 5.1-dev too).
[2005-08-03 23:09:08] mdpm2 at rohms dot com
Description:
The use of extract($GLOBALS,EXTR_REFS) appears to corrupt memory when
it is followed by an eval()'d series of code which includes another PHP
file.
This produces the following error:
httpd process:
[notice] child pid 46966 exit signal Bus error (10)
or
Bus error (core dumped) (from php standalone)
NOTE: This is a clarification of bug #33985
Reproduce code:
---
art.php (base script to run to reproduce error):
";
$fcategory=20;
// $stx="require_once(\"l-catlist.php\"); echo \"inside eval\";
catlist(1,0,9,3,$fcategory,0,1,1,99);";
$stx="require_once(\"l-catlist.php\"); echo \"inside eval\";";
echo 'EVAL string6='.$stx.'';
extract($GLOBALS,EXTR_REFS);
eval($stx);
echo "\n\ndone run";
?>
l-catlist.php (included from eval'd code):
";
return(0);
}
?>
Expected result:
For server to not crash at least..
Actual result:
--
There are two versions of the $stx assignment - I was debugging a
condition where I was having problems with the passing of parameters
between functions and I discovered when trimming down the code, I could
make the server completely crash with a simplified version so I believe
this is related to the problems I'm experiencing. If you can't
reproduce the error, try enabling the alternate assignment of $stx and
making sure the variables passed are accurate. However, I can
consistently crash the server using the above code and merely calling
art.php.
If you comment out "extract($GLOBALS,EXTR_REFS);" there are no
problems.
It's possible the above code could be even more simplified but I've
verified the error condition works with it as listed, under Apache
1_3.26/PHP 4.4.0
The problem can also be reproduced outside of apache:
#php -f art.php
EVAL string6=require_once("l-catlist.php"); echo "inside
eval";inside eval
done run
Bus error (core dumped)
NOTE: zend 20050606 was enabled - I'm not sure how to disable it.
--
Edit this bug report at http://bugs.php.net/?id=33989&edit=1
#30257 [Opn]: Unexpected result of xml_get_current_byte_index and xml_get_current_column_numb
ID: 30257
Updated by: [EMAIL PROTECTED]
Reported By: christoffer at natlikan dot se
Status: Open
-Bug Type: Documentation problem
+Bug Type: XML related
Operating System: *
PHP Version: 5CVS-2005-02-02
New Comment:
It's so weird that it should be rather fixed than documented:
All functions point to the end of a tag instead of beginning. (it can
be documented)
xml_get_current_byte_index() and xml_get_current_column_number() behave
unpredictable (it should be fixed):
CN=42, BI=4
CN=42, BI=5
CN=42, BI=4
CN=39, BI=40
Another problem is with attribute values and whitespace. They are not
counted to CN (it should be fixed):
CN=41, BI=45
CN=41, BI=46
CN=41, BI=46
CN=41, BI=48
Such a weird behavior is nearly undocumentable and unusable for sure.
Previous Comments:
[2005-08-01 00:37:06] [EMAIL PROTECTED]
This difference is caused by the fact that in PHP5 we use libxml
instead of expat by default.
To get the expat behaviour, you can always compile PHP with
--with-expat-dir=/path/to/expat
This change in behaviour needs to be documented though.
[2004-09-30 01:27:16] olivier at samalyse dot com
I'm experiencing similar troubles with xml_get_current_byte_index().
But I don't agree with the expected result christoffer proposes.
Actually, in php4 xml_get_current_byte_index() behaves perfectly to me.
Using the test code below with php version 4.3.4 produces :
ElementOpen - Row: 2 Col: 0 BIndex: 44
ElementOpen - Row: 4 Col: 1 BIndex: 61
ElementOpen - Row: 5 Col: 2 BIndex: 67
ElementClose - Row: 5 Col: 8 BIndex: 73
ElementClose - Row: 6 Col: 1 BIndex: 79
ElementClose - Row: 7 Col: 0 BIndex: 84
Byte Index 44 points at the beginning of the tag :
^
That is fine.
Now, if you omit the xml declaration '', using php5, you will obtain :
ElementOpen - Row: 1 Col: 5 BIndex: 8
ElementOpen - Row: 3 Col: 8 BIndex: 19
ElementOpen - Row: 4 Col: 11 BIndex: 25
ElementClose - Row: 4 Col: 15 BIndex: 33
ElementClose - Row: 5 Col: 18 BIndex: 39
ElementClose - Row: 6 Col: 21 BIndex: 44
Byte index 8 does not point at the beginning of the tag anymore, but at
its end :
^
In my particular case (XML indexing/marshalling) that's far less
usable. Some may consider that's no bug, but it breaks backward
compatibility with php4.
Now, if you let the xml declaration in place, this function does not
produce anything relevant anymore. As Christoffer reports, parsing this
xml document when it includes '' will produce :
ElementOpen - Row: 2 Col: 5 BIndex: 11
ElementOpen - Row: 4 Col: 8 BIndex: 22
ElementOpen - Row: 5 Col: 11 BIndex: 28
ElementClose - Row: 5 Col: 15 BIndex: 36
ElementClose - Row: 6 Col: 18 BIndex: 42
ElementClose - Row: 7 Col: 21 BIndex: 47
In this later case, what seems to happen is that the xml declaration
byte length is badly evaluated. If you add to this the fact that the
returned byte index points at the end of the tag (php5) instead of the
beginning of the tag (php4), it really starts to look like random
output...
[2004-09-27 20:36:13] christoffer at natlikan dot se
Description:
xml_get_current_byte_index and xml_get_current_column_number returns
unexpected values when the XML contains a XML declaration. Using
php5.0-win32-200409270830 and Apache/1.3.31.
Reproduce code:
---
");
}
function elementClose($parser, $elementName) {
echo("ElementClose - Row: " .
xml_get_current_line_number($parser) .
" Col: " . xml_get_current_column_number($parser) .
" BIndex: " . xml_get_current_byte_index($parser) .
"");
}
$parser = xml_parser_create();
xml_parser_set_option($parser, XML_OPTION_CASE_FOLDING, false);
xml_set_element_handler($parser, "elementOpen", "elementClose");
$xml =
"\n" .
"\n" .
"\ttest\n" .
"\t\n" .
"\t\tfoo\n" .
"\t\n" .
"";
xml_parse($parser, $xml);
xml_parser_free($parser);
?>
Expected result:
ElementOpen - Row: 2 Col: 10 BIndex: 52
ElementOpen - Row: 4 Col: 8 BIndex: 63
ElementOpen - Row: 5 Col: 11 BIndex: 69
ElementClose - Row: 5 Col: 9 BIndex: 73
ElementClose - Row: 6 Col: 2 BIndex: 79
ElementClose - Row: 7 Col: 1 BIndex: 85
Actual result:
--
ElementOpen - Row: 2 Col: 5 BIndex: 11
ElementOpen - Row: 4 Col: 8 BIndex: 22
ElementOpen - Row: 5 Col: 11 BIndex: 28
ElementClose - Row: 5 Col: 15 BIndex: 36
ElementClose - Row: 6 Col: 18 BIndex: 42
ElementClose - Row: 7 Col: 21 BIndex: 47
--
#33871 [Com]: No daylight savings time
ID: 33871
Comment by: xczimi at sztaki dot hu
Reported By: jeremy at techtrav dot com
Status: Assigned
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
Assigned To: derick
New Comment:
I unpacked both 5.0.4, 5.1.0b3 and the latest code to my Win XP box,
and tried the following in command line:
C:\devtool>php-5.1.0b3\php -r "echo date('r');"
Thu, 04 Aug 2005 08:05:40 +
C:\devtool>php-5.0.4\php -r "echo date('r');"
Thu, 04 Aug 2005 10:05:45 +0200
C:\devtool>php-latest\php -r "echo date('r');"
Thu, 04 Aug 2005 08:10:33 +
I think the oly problem is that php doesn't read the timezone of the
Operating system.
regards,
Czimi
Previous Comments:
[2005-07-26 18:21:13] jeremy at techtrav dot com
I am Central Standard Time in MN and we are on Day light Savings time.
[2005-07-26 18:16:49] [EMAIL PROTECTED]
This could be also a timezone issue.
What's your TZ ?
[2005-07-26 18:12:59] jeremy at techtrav dot com
I have upgraded to the newest snap as you have requested and I am still
getting the same results. PHP 5.0.4 returns the correct time. PHP
5.1.X returns the wrong time. Could this be an operating system issue?
I am on Windows XP with Apache 2.
[2005-07-26 18:05: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
>you get the expected result:
No, *I* get the expected result with both versions.
[2005-07-26 18:02:13] jeremy at techtrav dot com
you get the expected result:
string(19) "10/30/2005 23:10:00" string(19) "10/31/2005 00:10:00"
However in PHP 5.1.X I get:
string(19) "10/31/2005 00:10:00" string(19) "10/31/2005 00:10:00"
Which is wrong.
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/33871
--
Edit this bug report at http://bugs.php.net/?id=33871&edit=1
#30519 [Opn->Csd]: Interface not existing says Class not found
ID: 30519 Updated by: [EMAIL PROTECTED] Reported By: jsgoupil at lookstrike dot com -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: * PHP Version: 5CVS-2005-06-19 Assigned To: dmitry New Comment: Works as expected with latest CVS snapshot. DO NOT REOPEN BUGS if you HAVE NOT tested with LATEST CVS Previous Comments: [2005-08-04 06:10:00] [EMAIL PROTECTED] Reproducible in 5.1.0b2 [2005-06-24 10:46:14] [EMAIL PROTECTED] Fixed in CVS HEAD and PHP_5_0. [2004-10-21 20:48:56] jsgoupil at lookstrike dot com Description: If you specify an interface that not exists to a class, the output error is saying a "wrong" message... Reproduce code: --- Expected result: Fatal error: Interface 'a' not found in D:\www\LookStrike\ls_lite\a.php on line 2 Actual result: -- Fatal error: Class 'a' not found in D:\www\LookStrike\ls_lite\a.php on line 2 -- Edit this bug report at http://bugs.php.net/?id=30519&edit=1
#33987 [Opn->Fbk]: .php file in ErrorDocument causes apache crash
ID: 33987 Updated by: [EMAIL PROTECTED] Reported By: php dot net at sharpdreams dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Win32 (XP SP2) PHP Version: 5CVS-2005-08-03 New Comment: What do you get in the apache error_log when this problem happens? Are you sure it really crashes..? Previous Comments: [2005-08-04 01:37:03] php dot net at sharpdreams dot com LoadModule php5_module "C:/www/apache2/PHP5-1/php5apache2.dll" AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps PHPIniDir "C:/www/apache2/php5-1" [2005-08-03 22:47:58] [EMAIL PROTECTED] How have you enabled PHP in the httpd.conf file? (what lines did you add there to enable it..) [2005-08-03 22:17:11] php dot net at sharpdreams dot com This only seems to happen in Win32, works fine under our BSD boxes. Windows XP SP2, Apache 2/2.0.54, PHP 5.1.0-dev (built: Aug 3 2005 20:36:22). Changing my error document to anything other than a PHP file works (e.g., ErrorDocument error.html or /cgi-bin/error.pl). [2005-08-03 22:02:52] php dot net at sharpdreams dot com Tested on 5.0.3 release and it works fine. Some kind of regression between 5.0.3 and 5.1CVS. [2005-08-03 21:46:05] php dot net at sharpdreams dot com Description: Using recent PHP5.1 CVS snapshots on Win32, Apache2 crashes when a .php file is set as an ErrorDocument in .htaccess. There are similiar bugs (21074, 19793) that are marked closed. This was working with snapshots from a few weeks ago. Reproduce code: --- .htaccess - ErrorDocument 404 /error.php?status=404 /error.php - die( "File Not Found!" ); Expected result: File Not Found! Actual result: -- Apache2 crashes. -- Edit this bug report at http://bugs.php.net/?id=33987&edit=1
#33985 [Fbk->Bgs]: variable corruption in nested functions using extract()
ID: 33985 Updated by: [EMAIL PROTECTED] Reported By: mdpm2 at rohms dot com -Status: Feedback +Status: Bogus Bug Type: Variables related Operating System: FreeBSD 4.5 PHP Version: 4.4.0 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. One report is enough.. Previous Comments: [2005-08-03 21:41:03] [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 , 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 to avoid embedding huge scripts into the report. [2005-08-03 20:53:05] mdpm2 at rohms dot com Description: This problem was introduced after PHP 4.3.6 (last known version where it wasn't reproducable) and is still present in 4.4.0 Functions are unable to reference passed variables if they are called within a parent function that executes: extract($GLOBALS,EXTR_REFS); Prior to 4.4.0, referenced vars and globals would contain random other variable values; as of 4.4.0 they're NULL or 0. I'm trying to develop some code to isolate the problem but my error appears within a function that is recursive, but even the first iteration of the function does not receive the variable values passed as arguments. I have to assume this may be some issue with the way the compiler/optimizer handles the code during compilation. -- Edit this bug report at http://bugs.php.net/?id=33985&edit=1
#33992 [Opn->Bgs]: strtotime("sunday") on last week reports wrong year
ID: 33992
Updated by: [EMAIL PROTECTED]
Reported By: wim dot delvaux at adaptiveplanet dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: linux debian SID
PHP Version: 4.3.11
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
Previous Comments:
[2005-08-04 05:16:02] wim dot delvaux at adaptiveplanet dot com
Description:
strftime( "%A %e %B %G",$FY_FirstDayOfWeek)
prints monday 26 december 2005
which is correct, however
strftime( "%A %e %B %G",strtotime("sunday",
$FY_FirstDayOfWeek))
prints
zondag 1 januari 2005
which should be 2006 no ??
Reproduce code:
---
strftime( "%A %e %B %G",$FY_FirstDayOfWeek)
strftime( "%A %e %B %G",strtotime("sunday",$FY_FirstDayOfWeek))
and set $FY_FirstDayOfWeek to monday 26 december 2005
Expected result:
that the year 2006 is returned
--
Edit this bug report at http://bugs.php.net/?id=33992&edit=1
#33993 [Opn->Csd]: strtotime("sunday") on last week reports wrong year
ID: 33993
Updated by: [EMAIL PROTECTED]
Reported By: wim dot delvaux at adaptiveplanet dot com
-Status: Open
+Status: Closed
Bug Type: Date/time related
Operating System: linux debian SID
PHP Version: 4.3.11
New Comment:
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.
Fixed in PHP 5.1, won't fix in PHP 4.
Previous Comments:
[2005-08-04 05:16:24] wim dot delvaux at adaptiveplanet dot com
Description:
strftime( "%A %e %B %G",$FY_FirstDayOfWeek)
prints monday 26 december 2005
which is correct, however
strftime( "%A %e %B %G",strtotime("sunday",
$FY_FirstDayOfWeek))
prints
zondag 1 januari 2005
which should be 2006 no ??
Reproduce code:
---
strftime( "%A %e %B %G",$FY_FirstDayOfWeek)
strftime( "%A %e %B %G",strtotime("sunday",$FY_FirstDayOfWeek))
and set $FY_FirstDayOfWeek to monday 26 december 2005
Expected result:
that the year 2006 is returned
--
Edit this bug report at http://bugs.php.net/?id=33993&edit=1
