#21507 [NEW]: GET data containing # is ignored
From: [EMAIL PROTECTED] Operating system: Linux / Apache PHP version: 4.2.3 PHP Bug Type: *General Issues Bug description: GET data containing # is ignored I had a page where I was passing colour info to a script using the standard html numeric scheme - e.g. pulldown.php?out=#c0c0ff&over=#2020ff&item=#ff but the params were not received by the receiving script if the hash sign was used. I do not know if this is a PHP issue or an apache one but what I assume is happening is that something thinks that a reference is being made to an internal anchor. perhaps urlencoding culd have helped - and I had a workaround so this is not really high priority - Dave. -- Edit bug report at http://bugs.php.net/?id=21507&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21507&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21507&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21507&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21507&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21507&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21507&r=support Expected behavior: http://bugs.php.net/fix.php?id=21507&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21507&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21507&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21507&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21507&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21507&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21507&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21507&r=gnused
#17897 [Com]: POST form variables are empty
ID: 17897 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache2 related Operating System: Linux PHP Version: 4.2.1 New Comment: just to say thanks, this thread has just solved a problem with an ASP based system I am writing. Dreamweaver MX places form actions in as script sources by default, and so does not always put full url in the action field. As such all my post variables dissapeared, then I found this form, hard coded the action page and it worked ! Previous Comments: [2003-01-03 07:40:16] [EMAIL PROTECTED] Following extraction helped me to solve the problem that, variables are missing in the *.php after submition. >>Hi there... The problem is actually that in PHP 4.2, Register Globals is automatically defaulted to OFF. This means that variables that were normally in the global space such as GET and POST variables are no longer in the global space by default. PHP Announcement: http://www.php.net/release_4_2_0.php You can still force the old default behavior by changing the php.ini file and set the value for register_globals to "On". This will allow you to access the variables as they are named in the forms Documentation: http://www.php.net/manual/en/configuration.php#ini.register-globals << By the way, I found this Information on expert-exchange.com http://www.experts-exchange.com/Web/Web_Languages/PHP/Q_20293768.html My configuration: PHP 4.2.3 Apache 2.0.43 Windows 2k [2002-12-13 21:25:05] [EMAIL PROTECTED] I think the problem is PHP4. Because I installed PHP on both Apache and IIS of W2k. I got the same problem. The following are the test program (test.php). TEST I always get empty Arrays. I never imagine that such simple function have bugs in PHP, or I know to little about the PHP settings! Who can HELP!!! My system cannot progress!!! [2002-11-18 03:03:47] [EMAIL PROTECTED] ok the solution to my problem is simple - I am using AddOutputFilter PHP;INCLUDES .php so the post variables are missing - thats because you need also to set AddInputFilter PHP .php otherwise Apache2 will not forward the POST vars! [2002-09-21 02:20:42] [EMAIL PROTECTED] Thanks [EMAIL PROTECTED]! Adding "AddType application/x-httpd-php .php" to the conf file worked for me. PHP 4.2.3 APACHE 2.0.40 on WindowsXP [2002-09-06 14:12:36] [EMAIL PROTECTED] this helped me... LoadModule php4_module php4apache2.dll AddType application/x-httpd-php .php this doen't work #LoadModule php4_module php4apache2.dll # #SetOutputFilter PHP # The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/17897 -- Edit this bug report at http://bugs.php.net/?id=17897&edit=1
#18648 [Com]: Single entry form POST gives incorrect variable content
ID: 18648 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: HTTP related Operating System: Tru64 PHP Version: 4.2.2 New Comment: I also get the same problem with Linux RH8.0 I'm running apache 2.0.40-8 and php-4.2.2-8.0.5 Test: I tested this workaround by inserting into one of my forms and it works: Previous Comments: [2002-10-23 08:30:10] [EMAIL PROTECTED] Hi, I get the same problem with Linux RH8.0 using the default RPMs (which includes apache part deux). As a workaround I am adding: into my one field forms. thanks, josh. [2002-09-11 11:49:02] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-08-15 23:09:06] [EMAIL PROTECTED] Tested this with latest snapshot and Apache 1.3.26 on Tru64, seems to work fine. So Jani might be right with his Apache2-Guess. [2002-08-15 07:15:47] [EMAIL PROTECTED] Common for both cases seems to be Apache2..please try with Apache 1.3.26 (and the latest snapshot from today, url above). Apache2 support is experimental btw. [2002-08-15 06:08:55] [EMAIL PROTECTED] HelloAll, I can confirm this issue. I have the same problem on solaris, linux platforms. I've downloaded snapshot from 15082002, but it is the same on my Linux RH7.3 platform. Here are my configure options ./configure' '--with-apxs2=/internet/www/httpd-2.0.39/bin/apxs' '--with-config-file-path=/internet/www/' '--disable-debug' '--enable-sigchild' '--with-gdbm' '--with-zlib' '--enable-track-vars' '--enable-magic-quotes' '--with-dbase' '--with-gd' '--with-ttf' '--with-mysql=/opt/mysql/mysql' '--enable-ftp' '--with-gettext' '--with-iconv=/usr/local' '--enable-trans-sid' '--with-pdflib' '--enable-xml' '--enable-xslt' '--with-xslt-sablot' '--with-dom' '--with-pgsql=/opt/pgsql' '--enable-wddx' '--with-pear=/internet/www/php/' '--enable-mailparse' '--with-xmlrpc' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' 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/18648 -- Edit this bug report at http://bugs.php.net/?id=18648&edit=1
#20793 [NEW]: big selection with array_rand() works bad EVEN with srand()
From: [EMAIL PROTECTED]
Operating system: Linux (redhat6.2) 2.2.14-5.0smp
PHP version: 4.2.3
PHP Bug Type: Arrays related
Bug description: big selection with array_rand() works bad EVEN with srand()
I use array_rand() to randomize an array that can have three different
sizes, 450, 800 and 1152. With 450 array_rand works great. But when I try
to select 800 and 1152 indexes with array_rand(), array_rand seems to seed
higher number. I everycase I always get the 25 last indexes picked! Pretty
weird! It seems to favor the last number!
I have tried:
srand ((float) microtime() * 1000);
srand ((float) microtime() * 100);
But that didn't helped:
Here's my code:
if($bricks==1) $tempArrValue=450;
if($bricks==2) $tempArrValue=800;
if($bricks==3) $tempArrValue=1152;
$brickArray = array();
for($i=1;$i<=$tempArrValue;$i++){
$brickArray[$i]=$i;
}
srand ((float) microtime() * 1000);
$brickArray2 = array_rand($brickArray, sizeof($brickArray)-3);
for($i=0;$ihttp://bugs.php.net/?id=20793&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20793&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20793&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20793&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20793&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20793&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20793&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20793&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20793&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20793&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20793&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20793&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20793&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20793&r=isapi
#20793 [Opn]: big selection with array_rand() works bad EVEN with srand()
ID: 20793
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Arrays related
Operating System: Linux (redhat6.2) 2.2.14-5.0smp
PHP Version: 4.2.3
New Comment:
http://www.arthistory.cc/info.php for my php info
Previous Comments:
[2002-12-03 11:21:49] [EMAIL PROTECTED]
I use array_rand() to randomize an array that can have three different
sizes, 450, 800 and 1152. With 450 array_rand works great. But when I
try to select 800 and 1152 indexes with array_rand(), array_rand seems
to seed higher number. I everycase I always get the 25 last indexes
picked! Pretty weird! It seems to favor the last number!
I have tried:
srand ((float) microtime() * 1000);
srand ((float) microtime() * 100);
But that didn't helped:
Here's my code:
if($bricks==1) $tempArrValue=450;
if($bricks==2) $tempArrValue=800;
if($bricks==3) $tempArrValue=1152;
$brickArray = array();
for($i=1;$i<=$tempArrValue;$i++){
$brickArray[$i]=$i;
}
srand ((float) microtime() * 1000);
$brickArray2 = array_rand($brickArray, sizeof($brickArray)-3);
for($i=0;$ihttp://bugs.php.net/?id=20793&edit=1
#20793 [Fbk->Opn]: big selection with array_rand() works bad EVEN with srand()
ID: 20793
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Arrays related
Operating System: Linux (redhat6.2) 2.2.14-5.0smp
PHP Version: 4.2.3
New Comment:
I will test the snapshot this weekend, I have no access to a test
machine earlier
Ps, array_rand($brickArray, sizeof($brickArray)-3);
should be array_rand($brickArray, sizeof($brickArray));,
the error occur with both! Ds
Previous Comments:
[2002-12-03 11:28:27] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-12-03 11:24:16] [EMAIL PROTECTED]
http://www.arthistory.cc/info.php for my php info
[2002-12-03 11:21:49] [EMAIL PROTECTED]
I use array_rand() to randomize an array that can have three different
sizes, 450, 800 and 1152. With 450 array_rand works great. But when I
try to select 800 and 1152 indexes with array_rand(), array_rand seems
to seed higher number. I everycase I always get the 25 last indexes
picked! Pretty weird! It seems to favor the last number!
I have tried:
srand ((float) microtime() * 1000);
srand ((float) microtime() * 100);
But that didn't helped:
Here's my code:
if($bricks==1) $tempArrValue=450;
if($bricks==2) $tempArrValue=800;
if($bricks==3) $tempArrValue=1152;
$brickArray = array();
for($i=1;$i<=$tempArrValue;$i++){
$brickArray[$i]=$i;
}
srand ((float) microtime() * 1000);
$brickArray2 = array_rand($brickArray, sizeof($brickArray)-3);
for($i=0;$ihttp://bugs.php.net/?id=20793&edit=1
#20793 [Opn->Bgs]: big selection with array_rand() works bad EVEN with srand()
ID: 20793
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: Linux (redhat6.2) 2.2.14-5.0smp
PHP Version: 4.2.3
New Comment:
I'm terrible sorry the cause is most certain mysqlbased, for some
reason the first 100'rows contains almost 50% of number betweens
1000-1152 (from a random selection of 1-1152) weird.
But the with the script:
$tempArrValue=1000;
$brickArray = array();
for($i=1;$i<=$tempArrValue;$i++){
$brickArray[$i]=$i;
}
srand ((float) microtime() * 1000);
$brickArray2 = array_rand($brickArray, sizeof($brickArray));
$temp = 0;
for($i=0;$i<=250;$i++){
$temp = $temp + $brickArray2[$i];
}
echo $temp / 250;
I did get a correct answer, recieved number around 500.
Again I'm terrible sorry for taking your time, please contact me of you
want me to test something other, or anything else I can do.
Best Regards Dave
Previous Comments:
[2002-12-03 12:35:39] [EMAIL PROTECTED]
Here's something to test properly:
\n" :
"\n";
print("$string$nl");
}
$bricks = (isset($argv[1])) ? $argv[1] : 1;
if($bricks==1) $tempArrValue=450;
if($bricks==2) $tempArrValue=800;
if($bricks==3) $tempArrValue=1152;
$brickArray = array();
for($i=1;$i<=$tempArrValue;$i++){
$brickArray[$i]=$i;
}
srand ((float) microtime() * 1000);
$brickArray2 = array_rand($brickArray, sizeof($brickArray));
for($i=0;$i {$brickArray2[$i]}");
}
?>
I can't reproduce it - in fact, the following quick-hack-shell-tester
doesn't yield any output:
#!/bin/ksh
typeset -i COUNTER=1
while [ $COUNTER -lt 100 ]; do
./test_array_rand.php 3 | awk '{print $3}' | sort | perl -n -e
'print if $_ eq $previous; $previous=$_'
COUNTER=`expr ${COUNTER} + 1`
done
You should probably look at the query, rather than at rand. But then
again - if the above yields output, report back.
[2002-12-03 11:35:19] [EMAIL PROTECTED]
I will test the snapshot this weekend, I have no access to a test
machine earlier
Ps, array_rand($brickArray, sizeof($brickArray)-3);
should be array_rand($brickArray, sizeof($brickArray));,
the error occur with both! Ds
[2002-12-03 11:28:27] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-12-03 11:24:16] [EMAIL PROTECTED]
http://www.arthistory.cc/info.php for my php info
[2002-12-03 11:21:49] [EMAIL PROTECTED]
I use array_rand() to randomize an array that can have three different
sizes, 450, 800 and 1152. With 450 array_rand works great. But when I
try to select 800 and 1152 indexes with array_rand(), array_rand seems
to seed higher number. I everycase I always get the 25 last indexes
picked! Pretty weird! It seems to favor the last number!
I have tried:
srand ((float) microtime() * 1000);
srand ((float) microtime() * 100);
But that didn't helped:
Here's my code:
if($bricks==1) $tempArrValue=450;
if($bricks==2) $tempArrValue=800;
if($bricks==3) $tempArrValue=1152;
$brickArray = array();
for($i=1;$i<=$tempArrValue;$i++){
$brickArray[$i]=$i;
}
srand ((float) microtime() * 1000);
$brickArray2 = array_rand($brickArray, sizeof($brickArray)-3);
for($i=0;$ihttp://bugs.php.net/?id=20793&edit=1
#20948 [NEW]: DomElement->get_elements_by_tagname is now recursive
- Count | Node| Comment -- 1 | node_one| one 2 | node_firstTwo | first two, count should be 1 1 | node_four | four 1 | node_secondTwo | second two == Hopefully you can see what I'm trying to show here. The fact that 4.3.0RC3 finds the node_four and thus the node_secondTwo shows that DomElement->get_elements_by_tagname is recursive. Since PHP support for DOM XML is experimental, this might be a feature rather than a bug. If that's the case, maybe a parameter could be added to the function to select whether or not to traverse deeper into the tree. Thanks Dave Note: this was tested with libxml2-2.4.21 installed. Everything on the system is identical for each run above except for the php binary. -- Edit bug report at http://bugs.php.net/?id=20948&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20948&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20948&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20948&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20948&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20948&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20948&r=support Expected behavior: http://bugs.php.net/fix.php?id=20948&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20948&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20948&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20948&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20948&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20948&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20948&r=isapi
Bug #14865 Updated: php4apache.dll - phpinfo error - winXP - Apache
ID: 14865 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Apache related Operating System: Win XP Prof PHP Version: 4.1.1 New Comment: Same problem... OS: Windows XP Professional (5.1.2600 Build 2600) PHP: 4.2.0 Win32 Apache: 2.35 Win32 PHP Installed as module Testing Apache Config: "Cannot load c:/Program Files/PHP/sapi/php4apache.dll into server: The specified module could not be found." [Apache will not start] Keep me informed. Previous Comments: [2002-04-05 06:34:55] [EMAIL PROTECTED] When you updated, did you also update the php4ts.dll ?? Try PHP 4.2.0RC2 from http://www.php.net/~derick/ (and don't forget to replace php4ts.dll in your system with the one in that package) [2002-04-05 02:30:23] [EMAIL PROTECTED] Same problems as everyone else has, I didn't realize it wasn't me until I saw this post. I have: OS: Windows XP Professional (Build: 2600) PHP: 4.2.0RC1 Apache: 1.3.23 PHP Installed as module First time I noticed this was with phpinfo() flashing like 10 times and then displaying the phpinfo page, or sometimes after the flashing would display dns error page. It's not something that happens every time, and some days are also better than others and I don't expierience any problems related to this. In fact when I'm using 'localhost' this doesn't happen to me. And in fact when I surf the pages myself, phpinfo loads just fine. But as soon as someone else tries to run my scripts it starts tweaking out on them. Every time they try they say phpinfo page will load anywhere from %15 to like %90 and then it will just cut off or turn into "compiled code" as they put it, or simply...garbage. The point at which it starts to garble or cut off is random and unpredictable. As soon as anyone gets a fix for this it would be great if they would let everyone know! :) It's annoying not being able to share my code I've worked so hard on with other people... [2002-04-03 20:54:29] [EMAIL PROTECTED] I get a similar difficulty, but with ANY scripts no matter how small or large. 90% of the time it works perfectly, then all of a sudden PHP decides to spew a parse error or some other random phenomenon - even a single one line script will eventually suffer this fault. I experienced this when I moved to PHP 4.1.x, so reverted back to 4.0.6 which does not have the problem. Unfortunately 4.1.2 is a security fix so obviously have to upgrade, and now having to live with this problem. Not sure if its related, but 4.1.x also causes Apache's memory use to grow and grow and GROW until eventually a malloc fault occurrs. Sometimes Apache will restart, sometimes just crash. Again 4.0.6 has no such problem, just 4.1.x - had no choice but to configure Apache to self-restart every few hundred hits to overcome this memory leak. This is all with PHP as a Apache module. [2002-03-25 15:38:20] [EMAIL PROTECTED] I too am having the same problem. WinXP, Apache/1.3.22 (Win32), PHP/4.1.3-dev, mod_perl/1.26. PHP installed as a module. I haven't tried using it in CGI mode. It's not just phpinfo(). It happens regularly. Try going to: http://singularity.homedns.org/calendar/index.php Hit reload a few times, move to another month, etc. Eventually it will hose up. Spews garbage characters in the middle of the page. I understand going back to 4.0.6 seems to fix it, but I'd rather not. Any help would be..wellhelpful. IanW IanW [2002-03-22 00:24:26] [EMAIL PROTECTED] Another instance: I have a page that only contains and nothing else. PHP ver: 4.1.2 Machine: WinXP Pro HTTPD:Apache, PHP as a module When I browse to the page on my local machine (localhost) I get strange behaviour. I get a large number of instant redirects - in other words, the browser sits there redirecting itself to the same page for about 10 seconds (maybe 50 redirects in all). Finally the page either displays properly, or I get a DNS server not found error page in my browser. It's only started doing this since I upgraded from 4.0.6 to 4.1.2. I have just installed 4.2.0 RC1, but it makes no difference. If I go back to 4.0.6, it's fine. You can try this yourself. Go to: http://mvirtue.myip.org/test/index.php and see what you get. I got a friend of mine to try it from his machine, and he briefly saw the first few lines of the PHP info screen, and then was instantly redirected to a DNS error page. Often the page displays perfectly the first time you go there. It's only when you hit "Refresh" do you
Bug #16898 Updated: type convertation problem in pow()
ID: 16898
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: *Math Functions
Operating System: Linux
PHP Version: 4.2.0
New Comment:
I have the same problem, but on windows xp.
The values are being selected back from mysql via ADODB. The values
being used (in variables) are 2 and 0 eg pow($value1,$value2) where
value1 = 2 and value2 = 0
Previous Comments:
[2002-04-29 06:28:21] [EMAIL PROTECTED]
PHP automagically tries to convert the passed data to a number
representation.
Please paste the exact values you are using to call this pow()
[2002-04-29 06:17:23] [EMAIL PROTECTED]
$result=mysql_query("SELECT id, cdate FROM newspaper WHERE
path='".substr($a, strrpos($a, "/")+1, strlen($a))."'") or die
(mysql_error());
$rec=mysql_fetch_array($result);
$e=pow(2, $rec[id]); //Warning!
it's looks like what pow() function can't convert $rec[id] variable
from string to integer automatically.
Using
$rec[id]=stettype($rec[id], "int");
helps
--
Edit this bug report at http://bugs.php.net/?id=16898&edit=1
Bug #16898 Updated: type convertation problem in pow()
ID: 16898
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: *Math Functions
Operating System: Linux
PHP Version: 4.2.0
New Comment:
Further to my last post, here is the code in question:
function NUM_HOLDS($level_hull)
{
global $level_factor;
return round(pow($level_factor, $level_hull) * 100);
}
as stated in the previous post, $level_factor = 2 and $level_hull = 0;
It also occurs on this line:
$shipspeed = pow($level_factor, $playerinfo[engines]);
Could it be because in my case, I am using an associative array as the
second value?
Previous Comments:
[2002-05-06 22:12:18] [EMAIL PROTECTED]
I have the same problem, but on windows xp.
The values are being selected back from mysql via ADODB. The values
being used (in variables) are 2 and 0 eg pow($value1,$value2) where
value1 = 2 and value2 = 0
[2002-04-29 06:28:21] [EMAIL PROTECTED]
PHP automagically tries to convert the passed data to a number
representation.
Please paste the exact values you are using to call this pow()
[2002-04-29 06:17:23] [EMAIL PROTECTED]
$result=mysql_query("SELECT id, cdate FROM newspaper WHERE
path='".substr($a, strrpos($a, "/")+1, strlen($a))."'") or die
(mysql_error());
$rec=mysql_fetch_array($result);
$e=pow(2, $rec[id]); //Warning!
it's looks like what pow() function can't convert $rec[id] variable
from string to integer automatically.
Using
$rec[id]=stettype($rec[id], "int");
helps
--
Edit this bug report at http://bugs.php.net/?id=16898&edit=1
Bug #16898 Updated: type convertation problem in pow()
ID: 16898
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: *Math Functions
Operating System: Linux
PHP Version: 4.2.0
New Comment:
This is a duplicate of 16944 which has been fixed.
Previous Comments:
[2002-05-06 22:18:14] [EMAIL PROTECTED]
Further to my last post, here is the code in question:
function NUM_HOLDS($level_hull)
{
global $level_factor;
return round(pow($level_factor, $level_hull) * 100);
}
as stated in the previous post, $level_factor = 2 and $level_hull = 0;
It also occurs on this line:
$shipspeed = pow($level_factor, $playerinfo[engines]);
Could it be because in my case, I am using an associative array as the
second value?
[2002-05-06 22:12:18] [EMAIL PROTECTED]
I have the same problem, but on windows xp.
The values are being selected back from mysql via ADODB. The values
being used (in variables) are 2 and 0 eg pow($value1,$value2) where
value1 = 2 and value2 = 0
[2002-04-29 06:28:21] [EMAIL PROTECTED]
PHP automagically tries to convert the passed data to a number
representation.
Please paste the exact values you are using to call this pow()
[2002-04-29 06:17:23] [EMAIL PROTECTED]
$result=mysql_query("SELECT id, cdate FROM newspaper WHERE
path='".substr($a, strrpos($a, "/")+1, strlen($a))."'") or die
(mysql_error());
$rec=mysql_fetch_array($result);
$e=pow(2, $rec[id]); //Warning!
it's looks like what pow() function can't convert $rec[id] variable
from string to integer automatically.
Using
$rec[id]=stettype($rec[id], "int");
helps
--
Edit this bug report at http://bugs.php.net/?id=16898&edit=1
Bug #17152: driver initialization failed in [script_name] on [line_num]
From: [EMAIL PROTECTED]
Operating system: RedHat 7.2
PHP version: 4.2.0
PHP Bug Type: DBM/DBA related
Bug description: driver initialization failed in [script_name] on [line_num]
When executing the following code:
\n";
$dba = dba_open("./test.db", "r", "ndbm");
?>
The following error message is encountered:
Warning: driver initialization failed in
/var/www/devuser/devbox-mx.dhs.org/www/test/test.php on line 5
PHP 4.2.0 was compiled with the following command:
'./configure' '--with-apxs=/usr/sbin/apxs' '--with-mysql' '--with-pgsql'
'--with-config-file-path=/etc' '--enable-track-vars'
'--disable-short-tags' '--disable-posix' '--with-curl' '--with-gettext'
'--with-ldap' '--with-zlib' '--with-dom' '--with-db'
'--with-gdbm=/usr/include/gdbm' '--with-ndbm=/usr/include/db1'
'--with-db2=/usr/include/db2' '--with-db3=/usr/include/db3'
--
Edit bug report at http://bugs.php.net/?id=17152&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17152&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17152&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17152&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17152&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17152&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17152&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17152&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17152&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17152&r=globals
Bug #17152 Updated: driver initialization failed in [script_name] on [line_num]
ID: 17152
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: DBM/DBA related
Operating System: RedHat 7.2
PHP Version: 4.2.0
New Comment:
The problem has further degraded...
Insteading getting a PHP warning about driver init failure, the page
fails to load, and I am getting all kinds of these messages in HTTPD's
error_log that read:
[notice] child pid [PID] exit signal Segmentation fault (11)
I'm convinced that this is a problem with PHP.
Previous Comments:
[2002-05-11 01:37:04] [EMAIL PROTECTED]
When executing the following code:
\n";
$dba = dba_open("./test.db", "r", "ndbm");
?>
The following error message is encountered:
Warning: driver initialization failed in
/var/www/devuser/devbox-mx.dhs.org/www/test/test.php on line 5
PHP 4.2.0 was compiled with the following command:
'./configure' '--with-apxs=/usr/sbin/apxs' '--with-mysql'
'--with-pgsql' '--with-config-file-path=/etc' '--enable-track-vars'
'--disable-short-tags' '--disable-posix' '--with-curl' '--with-gettext'
'--with-ldap' '--with-zlib' '--with-dom' '--with-db'
'--with-gdbm=/usr/include/gdbm' '--with-ndbm=/usr/include/db1'
'--with-db2=/usr/include/db2' '--with-db3=/usr/include/db3'
--
Edit this bug report at http://bugs.php.net/?id=17152&edit=1
Bug #17152 Updated: driver initialization failed in [script_name] on [line_num]
ID: 17152
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: DBM/DBA related
Operating System: RedHat 7.2
PHP Version: 4.2.0
New Comment:
Note the the above error (segfault) is encountered when the following
code is executed:
$dba = dba_open("./test.db", "r", "db2");
So the segfault is related to a different driver set
Previous Comments:
[2002-05-11 16:04:29] [EMAIL PROTECTED]
The problem has further degraded...
Insteading getting a PHP warning about driver init failure, the page
fails to load, and I am getting all kinds of these messages in HTTPD's
error_log that read:
[notice] child pid [PID] exit signal Segmentation fault (11)
I'm convinced that this is a problem with PHP.
[2002-05-11 01:37:04] [EMAIL PROTECTED]
When executing the following code:
\n";
$dba = dba_open("./test.db", "r", "ndbm");
?>
The following error message is encountered:
Warning: driver initialization failed in
/var/www/devuser/devbox-mx.dhs.org/www/test/test.php on line 5
PHP 4.2.0 was compiled with the following command:
'./configure' '--with-apxs=/usr/sbin/apxs' '--with-mysql'
'--with-pgsql' '--with-config-file-path=/etc' '--enable-track-vars'
'--disable-short-tags' '--disable-posix' '--with-curl' '--with-gettext'
'--with-ldap' '--with-zlib' '--with-dom' '--with-db'
'--with-gdbm=/usr/include/gdbm' '--with-ndbm=/usr/include/db1'
'--with-db2=/usr/include/db2' '--with-db3=/usr/include/db3'
--
Edit this bug report at http://bugs.php.net/?id=17152&edit=1
Bug #17107 Updated: exit() always reports exit status=255
ID: 17107 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.2.0 Assigned To: derick New Comment: Experiencing same problem on 4.2.0/Linux. Return from global scope does not seem to work for me though or else I would use it as an alternative. Is this fixed in CVS? -Dave Previous Comments: [2002-05-10 02:06:14] [EMAIL PROTECTED] I think I broke this, so I'll fix it too :) Derick [2002-05-08 21:44:49] [EMAIL PROTECTED] $ php -v 4.2.0 $ php -q $ echo $? 255 exit(n) always reports 255 (or -1) as exit status to the OS, regardless of the value it is passed as argument. The correct behavior according to the documentation would be to report n as exit status, or echo n if n is a string. The only workaround I could find is to use return from the global scope. Thank you :) -- Edit this bug report at http://bugs.php.net/?id=17107&edit=1
Bug #17107 Updated: exit() always reports exit status=255
ID: 17107 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.2.0 Assigned To: derick New Comment: The pcntl_exec worked good...Thank you. Ideally the exit status would work as discussed on the dev mailing list...exit(int) sets status as integer, exit(string) prints string. just tested on PHP 4.3.0-dev (cli) and still no exit status...;) Know where I should start hacking?? /sapi/cli ? Thanks for the pcntl tip! -Dave Previous Comments: [2002-05-13 14:10:48] [EMAIL PROTECTED] Here's another workaround for you if you have --enable-pcntl: $ php -q $ echo $? 123 [2002-05-13 13:47:19] [EMAIL PROTECTED] Experiencing same problem on 4.2.0/Linux. Return from global scope does not seem to work for me though or else I would use it as an alternative. Is this fixed in CVS? -Dave [2002-05-10 02:06:14] [EMAIL PROTECTED] I think I broke this, so I'll fix it too :) Derick [2002-05-08 21:44:49] [EMAIL PROTECTED] $ php -v 4.2.0 $ php -q $ echo $? 255 exit(n) always reports 255 (or -1) as exit status to the OS, regardless of the value it is passed as argument. The correct behavior according to the documentation would be to report n as exit status, or echo n if n is a string. The only workaround I could find is to use return from the global scope. Thank you :) -- Edit this bug report at http://bugs.php.net/?id=17107&edit=1
Bug #17200: page not found on form submissions
From: [EMAIL PROTECTED] Operating system: Win 2k PHP version: 4.1.2 PHP Bug Type: OpenSSL related Bug description: page not found on form submissions hello... recently i have had a problem with a SSL connection in my PHP form... after submit i recive a 404 error if i access the page via http:// rather than https:// i do not recive the error... PHP version is 4.1.2 Apache version 1.3.23 OS is Win 2k (IIS not installed) any help would be greatly apriciated... thnx, dave [EMAIL PROTECTED] -- Edit bug report at http://bugs.php.net/?id=17200&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17200&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17200&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17200&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17200&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17200&r=support Expected behavior: http://bugs.php.net/fix.php?id=17200&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17200&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17200&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17200&r=globals
Bug #17218: PHP 4.2.1 doesn't compile after ./configure
From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.2.1 PHP Bug Type: Compile Failure Bug description: PHP 4.2.1 doesn't compile after ./configure Solaris 8 machine, using gcc from sunfreeware.com, trying to compile php4.2.1 $ ./configure $ make Making all in Zend /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main-D_POSIX_PTHREAD_SEMANTICS -I../TSRM -g -O2 -prefer-non-pic -static -c -o zend_language_parser.lo `test -f zend_language_parser.c || echo './'`zend_language_parser.c In file included from zend_compile.h:24, from zend_language_parser.c:147: zend.h:55:19: unix.h: No such file or directory *** Error code 1 make: Fatal error: Command failed for target `zend_language_parser.lo' Current working directory /download/php-4.2.1/Zend *** Error code 1 make: Fatal error: Command failed for target `all-recursive' -- Edit bug report at http://bugs.php.net/?id=17218&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17218&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17218&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17218&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17218&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17218&r=support Expected behavior: http://bugs.php.net/fix.php?id=17218&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17218&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17218&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17218&r=globals
Bug #17218 Updated: PHP 4.2.1 doesn't compile after ./configure
ID: 17218 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.2.1 New Comment: Undefining HAVE_UNIX_H took care of the first problem and introduced a mysql compile failure. I don't know if this is new in 4.2.1 or not since for the 4.2.0 compile I used --with-mysql=/opt/mysql. (I'd only omitted it for the original test case since it was the simplest ./configure option that duplicated the error). I also needed undefine HAVE_SYS_SYSEXITS_H to get further in compilation, to then end up with this error (below). I'll look into this further tomorrow and see if I can nail down what's causing it. /bin/sh /download/php-4.2.1/libtool --silent --mode=link gcc -I. -I/download/php-4.2.1/ -I/download/php-4.2.1/main -I/download/php-4.2.1 -I/opt/apache-1.3.24/include -I/download/php-4.2.1/Zend -I/opt/mysql/include -I/download/php-4.2.1/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -DSOLARIS2=280 -DMOD_SSL=208108 -DEAPI -DEAPI_MM -DUSE_EXPAT -DSHARED_CORE -I/download/php-4.2.1/TSRM -g -O2 -prefer-pic -o libphp4.la -rpath /download/php-4.2.1/libs -avoid-version -L/usr/ucblib -L/opt/mysql/lib -R /usr/ucblib -R /opt/mysql/lib stub.lo Zend/libZend.la sapi/apache/libsapi.la main/libmain.la regex/libregex.la /download/php-4.2.1/ext/ctype/libctype.la /download/php-4.2.1/ext/mysql/libmysql.la /download/php-4.2.1/ext/pcre/libpcre.la /download/php-4.2.1/ext/posix/libposix.la /download/php-4.2.1/ext/session/libsession.la /download/php-4.2.1/ext/standard/libstandard.la /download/php-4.2.1/ext/xml/libxml.la TSRM/libtsrm.la -lpam -lmysqlclient -lz -lcrypt -lresolv -lresolv -lresolv -lm -ldl -lsocket -lsocket -lcrypt -ldl main/.libs/libmain.al: object main/.libs/libmain.al(main.lo) in archive is not object collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `libphp4.la' Current working directory /download/php-4.2.1 *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Previous Comments: [2002-05-14 18:09:40] [EMAIL PROTECTED] Could you have a look in main/php_config.h. Can you find a line that says #define HAVE_UNIX_H 1 If yes, could you try commenting that line out and compiling again. [2002-05-14 17:05:25] [EMAIL PROTECTED] Solaris 8 machine, using gcc from sunfreeware.com, trying to compile php4.2.1 $ ./configure $ make Making all in Zend /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main-D_POSIX_PTHREAD_SEMANTICS -I../TSRM -g -O2 -prefer-non-pic -static -c -o zend_language_parser.lo `test -f zend_language_parser.c || echo './'`zend_language_parser.c In file included from zend_compile.h:24, from zend_language_parser.c:147: zend.h:55:19: unix.h: No such file or directory *** Error code 1 make: Fatal error: Command failed for target `zend_language_parser.lo' Current working directory /download/php-4.2.1/Zend *** Error code 1 make: Fatal error: Command failed for target `all-recursive' -- Edit this bug report at http://bugs.php.net/?id=17218&edit=1
Bug #17218 Updated: PHP 4.2.1 doesn't compile after ./configure
ID: 17218 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.2.1 New Comment: Copying the 4.2.0 configure script over did the trick here as well. Let me know if you'd like me to run any other tests to help track down where the problem is. Thanks -- Dave Previous Comments: [2002-05-14 19:04:47] [EMAIL PROTECTED] Great. At least we have the problem diagnosed. [2002-05-14 18:56:11] [EMAIL PROTECTED] I copied the configure script from the 4.2.0 tarball and it seems to work, thanks for the hint. [2002-05-14 18:44:02] [EMAIL PROTECTED] I've just checked, and there were no changes made in configure script between 4.2.0 and 4.2.1 appart from version number and the register globals warning. The only significant thing is that the configure was built using autoconf 2.53 in 4.2.0 tarball, and with autoconf 2.13 in 4.2.1 due to some probles we were having with the latest version. Could you please try to copy configure script from 4.2.0 tarball over in 4.2.1 source and see if the build works? [2002-05-14 18:23:17] [EMAIL PROTECTED] Same problem here... after commenting out "#define HAVE_UNIX_H 1" I get a lot of warnings when compiling: In file included from ../main/php_config.h:2084, from zend_config.h:1, from zend.h:48, from zend_compile.h:24, from zend_language_parser.c:147: /usr/include/stdlib.h:79: warning: empty declaration In file included from ../main/php_config.h:2088, from zend_config.h:1, from zend.h:48, from zend_compile.h:24, from zend_language_parser.c:147: /usr/include/sys/types.h:339: warning: empty declaration /usr/include/sys/types.h:480: warning: empty declaration /usr/include/sys/types.h:481: warning: empty declaration and so on [2002-05-14 18:23:01] [EMAIL PROTECTED] Undefining HAVE_UNIX_H took care of the first problem and introduced a mysql compile failure. I don't know if this is new in 4.2.1 or not since for the 4.2.0 compile I used --with-mysql=/opt/mysql. (I'd only omitted it for the original test case since it was the simplest ./configure option that duplicated the error). I also needed undefine HAVE_SYS_SYSEXITS_H to get further in compilation, to then end up with this error (below). I'll look into this further tomorrow and see if I can nail down what's causing it. /bin/sh /download/php-4.2.1/libtool --silent --mode=link gcc -I. -I/download/php-4.2.1/ -I/download/php-4.2.1/main -I/download/php-4.2.1 -I/opt/apache-1.3.24/include -I/download/php-4.2.1/Zend -I/opt/mysql/include -I/download/php-4.2.1/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -DSOLARIS2=280 -DMOD_SSL=208108 -DEAPI -DEAPI_MM -DUSE_EXPAT -DSHARED_CORE -I/download/php-4.2.1/TSRM -g -O2 -prefer-pic -o libphp4.la -rpath /download/php-4.2.1/libs -avoid-version -L/usr/ucblib -L/opt/mysql/lib -R /usr/ucblib -R /opt/mysql/lib stub.lo Zend/libZend.la sapi/apache/libsapi.la main/libmain.la regex/libregex.la /download/php-4.2.1/ext/ctype/libctype.la /download/php-4.2.1/ext/mysql/libmysql.la /download/php-4.2.1/ext/pcre/libpcre.la /download/php-4.2.1/ext/posix/libposix.la /download/php-4.2.1/ext/session/libsession.la /download/php-4.2.1/ext/standard/libstandard.la /download/php-4.2.1/ext/xml/libxml.la TSRM/libtsrm.la -lpam -lmysqlclient -lz -lcrypt -lresolv -lresolv -lresolv -lm -ldl -lsocket -lsocket -lcrypt -ldl main/.libs/libmain.al: object main/.libs/libmain.al(main.lo) in archive is not object collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `libphp4.la' Current working directory /download/php-4.2.1 *** Error code 1 make: Fatal error: Command failed for target `all-recursive' 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/17218 -- Edit this bug report at http://bugs.php.net/?id=17218&edit=1
Bug #17249: phpinfo() no longer works under SSL
From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.2.1 PHP Bug Type: Scripting Engine problem Bug description: phpinfo() no longer works under SSL Just installed php 4.2.1 (over previous 4.2.0 installation). Did not make any changes to the apache conf or php.ini config (my php.ini is identical to php.ini-recommended except for expose_php = Off, though I've confirmed this happens with both Off and On). If I try to view .php pages under SSL, they all work except for a specific file containing only: --- begin file --- --- end file --- If, however, the phpinfo() call is within a larger script it works fine. For example, these both work: --- begin file --- --- end file --- --- begin file --- --- end file --- The error I receive is a browser popup: the URL (etc) has MIME type application/x-httpd-php. Saving the file shows that it contains the php source. This problem does not occur within the same set of files under a non-SSL enabled apache virtual host. -- Edit bug report at http://bugs.php.net/?id=17249&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17249&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17249&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17249&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17249&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17249&r=support Expected behavior: http://bugs.php.net/fix.php?id=17249&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17249&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17249&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17249&r=globals
Bug #17218 Updated: PHP 4.2.1 doesn't compile after ./configure
ID: 17218 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.2.1 New Comment: Configure output sent to mfischer by email since 4 files of ~ 100k each were attached (too large to paste into comment box). Previous Comments: [2002-05-15 13:53:52] [EMAIL PROTECTED] Could someone with access to solaris provide the full output of ./configure and config.log from both 2.13 and 2.52 for download ? Seems another detection thing we need to fix. [2002-05-15 13:50:45] [EMAIL PROTECTED] Same goes hereIf ya need any other testing on Solaris 8 or Solaris 7, please let me know. 4.2.1 compiled fine on Linux :) - Mike [2002-05-15 09:21:57] [EMAIL PROTECTED] Copying the 4.2.0 configure script over did the trick here as well. Let me know if you'd like me to run any other tests to help track down where the problem is. Thanks -- Dave [2002-05-14 19:04:47] [EMAIL PROTECTED] Great. At least we have the problem diagnosed. [2002-05-14 18:56:11] [EMAIL PROTECTED] I copied the configure script from the 4.2.0 tarball and it seems to work, thanks for the hint. 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/17218 -- Edit this bug report at http://bugs.php.net/?id=17218&edit=1
Bug #17218 Updated: PHP 4.2.1 doesn't compile after ./configure
ID: 17218 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.2.1 New Comment: Configure output and config.log are here: http://dsb3.com/debug/php/ Previous Comments: [2002-05-15 14:32:16] [EMAIL PROTECTED] Configure output sent to mfischer by email since 4 files of ~ 100k each were attached (too large to paste into comment box). [2002-05-15 13:53:52] [EMAIL PROTECTED] Could someone with access to solaris provide the full output of ./configure and config.log from both 2.13 and 2.52 for download ? Seems another detection thing we need to fix. [2002-05-15 13:50:45] [EMAIL PROTECTED] Same goes hereIf ya need any other testing on Solaris 8 or Solaris 7, please let me know. 4.2.1 compiled fine on Linux :) - Mike [2002-05-15 09:21:57] [EMAIL PROTECTED] Copying the 4.2.0 configure script over did the trick here as well. Let me know if you'd like me to run any other tests to help track down where the problem is. Thanks -- Dave [2002-05-14 19:04:47] [EMAIL PROTECTED] Great. At least we have the problem diagnosed. 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/17218 -- Edit this bug report at http://bugs.php.net/?id=17218&edit=1
Bug #17249 Updated: phpinfo() no longer works under SSL
ID: 17249 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: Solaris 8 PHP Version: 4.2.1 New Comment: I disagree. A one-line test case (as provided within the documentation) that behaves differently from php4.2.0 and php4.2.1 would indicate a bug (or discrepancy) has snuck into the code during the last release. The fact it can be altered depending on whitespace within the file and whether running through an SSL enabled host is merely additional information I have provided to try to aide it's resolution. I am not requesting support. I am reporting that php's behaviour has been changed, in what appears to me to be a buggish fashion. Previous Comments: [2002-05-15 14:37:47] [EMAIL PROTECTED] Sorry, but the bug system is not the appropriate forum for asking support questions. Your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Thank you for your interest in PHP. [2002-05-15 09:50:26] [EMAIL PROTECTED] Just installed php 4.2.1 (over previous 4.2.0 installation). Did not make any changes to the apache conf or php.ini config (my php.ini is identical to php.ini-recommended except for expose_php = Off, though I've confirmed this happens with both Off and On). If I try to view .php pages under SSL, they all work except for a specific file containing only: --- begin file --- --- end file --- If, however, the phpinfo() call is within a larger script it works fine. For example, these both work: --- begin file --- --- end file --- --- begin file --- --- end file --- The error I receive is a browser popup: the URL (etc) has MIME type application/x-httpd-php. Saving the file shows that it contains the php source. This problem does not occur within the same set of files under a non-SSL enabled apache virtual host. -- Edit this bug report at http://bugs.php.net/?id=17249&edit=1
Bug #17218 Updated: PHP 4.2.1 doesn't compile after ./configure
ID: 17218 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.2.1 New Comment: Confirmed here as well. CC=gcc does the trick. I'll take my configure output offline also. Thanks everyone who helped track down the problem! Previous Comments: [2002-05-16 09:15:38] [EMAIL PROTECTED] Ok. We can conclude that this is an autoconf bug with an easy workaround. Closing the bug report. [2002-05-16 09:06:33] [EMAIL PROTECTED] "export CC=gcc" solves the problems with the configure of 4.2.1! THANKS again p.s: I'm gonna delete the output files from our ftp directory [2002-05-15 18:34:32] [EMAIL PROTECTED] I can see that configure in 4.2.1 tarball wrongly tries to use cc instead of gcc in all the tests it fails. What happens if you try to run 4.2.1 configure with: CC=gcc ./configure ... [2002-05-15 14:39:13] [EMAIL PROTECTED] Here you can download the two outputs: ftp://ftp.tugraz.at/mirror/php/tmp/php-config/ [2002-05-15 14:38:49] [EMAIL PROTECTED] Configure output and config.log are here: http://dsb3.com/debug/php/ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/17218 -- Edit this bug report at http://bugs.php.net/?id=17218&edit=1
#19791 [NEW]: sapi_apache2.c incompatible type for argument 3 of `ap_register_output_filter'
From: [EMAIL PROTECTED] Operating system: Redhat 7.1 PHP version: 4.2.3 PHP Bug Type: Compile Failure Bug description: sapi_apache2.c incompatible type for argument 3 of `ap_register_output_filter' Using apache 2-0-39, configuring as ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql make then fails with sapi_apache2.c: In function `php_register_hook': sapi_apache2.c:567: incompatible type for argument 3 of `ap_register_output_filter' sapi_apache2.c:567: too many arguments to function `ap_register_output_filter' sapi_apache2.c:568: incompatible type for argument 3 of `ap_register_input_filter' sapi_apache2.c:568: too many arguments to function `ap_register_input_filter' -- Edit bug report at http://bugs.php.net/?id=19791&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19791&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19791&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19791&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19791&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19791&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19791&r=support Expected behavior: http://bugs.php.net/fix.php?id=19791&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19791&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19791&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19791&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19791&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19791&r=dst IIS Stability: http://bugs.php.net/fix.php?id=19791&r=isapi
#19791 [Bgs->Opn]: sapi_apache2.c incompatible type for argument 3 of `ap_register_output_filter'
ID: 19791 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Compile Failure Operating System: Redhat 7.1 PHP Version: 4.2.3 New Comment: I had checked for duplicate entries. The ones I found with the same compile error are over a year old, and have the response of either "user a newer version of Apache2", which I am, or "this has been fixed with a new release". I'm getting the fault with the latest full release. Previous Comments: [2002-10-06 20:09:01] [EMAIL PROTECTED] http://bugs.php.net/report.php: "Before you report a bug, make sure to search for similar bugs using the form at the top of the page or our advanced search page." If you really could not find anything (I should stop this sentence right here). [2002-10-06 19:56:02] [EMAIL PROTECTED] Using apache 2-0-39, configuring as ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql make then fails with sapi_apache2.c: In function `php_register_hook': sapi_apache2.c:567: incompatible type for argument 3 of `ap_register_output_filter' sapi_apache2.c:567: too many arguments to function `ap_register_output_filter' sapi_apache2.c:568: incompatible type for argument 3 of `ap_register_input_filter' sapi_apache2.c:568: too many arguments to function `ap_register_input_filter' -- Edit this bug report at http://bugs.php.net/?id=19791&edit=1
#19791 [Opn->Bgs]: sapi_apache2.c incompatible type for argument 3 of `ap_register_output_filter'
ID: 19791 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Redhat 7.1 PHP Version: 4.2.3 New Comment: OK, the problem goes away with Apache 2.0.43 Previous Comments: [2002-10-07 04:36:02] [EMAIL PROTECTED] I had checked for duplicate entries. The ones I found with the same compile error are over a year old, and have the response of either "user a newer version of Apache2", which I am, or "this has been fixed with a new release". I'm getting the fault with the latest full release. [2002-10-06 20:09:01] [EMAIL PROTECTED] http://bugs.php.net/report.php: "Before you report a bug, make sure to search for similar bugs using the form at the top of the page or our advanced search page." If you really could not find anything (I should stop this sentence right here). [2002-10-06 19:56:02] [EMAIL PROTECTED] Using apache 2-0-39, configuring as ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql make then fails with sapi_apache2.c: In function `php_register_hook': sapi_apache2.c:567: incompatible type for argument 3 of `ap_register_output_filter' sapi_apache2.c:567: too many arguments to function `ap_register_output_filter' sapi_apache2.c:568: incompatible type for argument 3 of `ap_register_input_filter' sapi_apache2.c:568: too many arguments to function `ap_register_input_filter' -- Edit this bug report at http://bugs.php.net/?id=19791&edit=1
Bug #14749 Updated: array_reduce() causes segmentation faults
ID: 14749
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: RedHat 7.1
PHP Version: 4.1.1
New Comment:
Configure line:
'./configure' '--with-apxs' '--with-mysql=/usr' '--with-xml'
'--enable-wddx' '--with-imap' '--with-gdbm'
Previous Comments:
[2002-02-11 23:12:07] [EMAIL PROTECTED]
Can you attach a copy of tree.xml to an email and send it to
[EMAIL PROTECTED]? Also, please update this bug report to include your
configure line.
Sean
[2001-12-28 17:27:13] [EMAIL PROTECTED]
This drove me crazy. array_reduce() causes segmentation faults when
used in a complex, recursive manner. I'm pretty sure it's
array_reduce() and not create_function() that's the culprit here. I'm
sorry I can't provide a simpler example, but I've been unable to
reprodce the crash otherwise. I'll try to describe what I'm doing to
the best of my abilities.
debug.php is an include that I use for dumping out nicely-formatted
data structures - it works like print_r() but cleaner. It's written
using functional techniques, so I'm using create_function() as a lambda
and array_reduce() as a reduction.
tree.xml is an XML file that I'm parsing into a data structure using
wddx_deserialize(). I thought that it was my deserialization that was
the problem when I was using XML-RPC, and switched to WDDX in hopes
that that would solve the crash problem. It didn't. It took a lot of
monkeying around before I figured out where the real problem was.
I don't know how to use GDB, and I don't really have any more time to
dedicate to this, so no backtrace. Sorry. I've experienced this problem
with PHP 4.1.0, 4.1.1, and 4.2.0-dev under RedHat 7.1 and Apache
1.3.22.
Here are my source files:
crash.php (this is the one to run)
debug.php:
$val) $result[] = array($key, $val);
return $result;
}
function debug_node($key, $val) {
return "-+ $key "
. "(" . gettype($val) .
")\n";
}
function debug_leaf($key, $val) {
return "-> $key = $val "
. "(" . gettype($val) .
")\n";
}
function debug_reduce($prep, $accum, $key_val) {
list($key, $val) = $key_val;
return "$accum$prep" . (is_array($val) ? debug_node($key,
$val)
. debug_tree("$prep |",
$val)
: debug_leaf($key,
$val));
}
function debug_tree($prep, $array) {
return array_reduce(array_items($array),
create_function('$a, $x',
"return debug_reduce('$prep', \$a, \$x);"),
'');
}
function debug_array($array) {
return "\n"
. debug_tree('|', $array) . '';
}
function debug_string($string) {
return "\n"
. nl2br($string) . "\n";
}
function debug($msg) {
?>
tree.xml:
About UsWho We Areabout/who2342
What We Doodooabout/what69aboutProductsproducts8699Servicesservices<
/array>Contact
Uscontact1
That's it. Good luck.
Peace,
Dave
--
Edit this bug report at http://bugs.php.net/?id=14749&edit=1
Bug #15059 Updated: compile fails when I add cyrus support
ID: 15059
Updated by: [EMAIL PROTECTED]
-Reported By: [EMAIL PROTECTED]
+Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: *Compile Issues
Operating System: SuSE Linux7.2 linux-2.4.9
PHP Version: 4.1.1
New Comment:
Its fixed by bug report 14671
Previous Comments:
[2002-01-22 18:51:31] [EMAIL PROTECTED]
Hi, I had the same problem!
Here a patch I made who worked so far form me.
What does that mean?
I have absolutely NO C knowledge. Just by comparing the effected line
with similar lines in cyrus.c and other ext files I generated it.
SO I HAVE NO CLUE WHAT I DID !!! - but it compiled.
I haven't installed PHP4 so far and tested the cyrus part.
May be someone with solid C knowledge could check what I did and if
there is a far change that it works.
And here finally the patch:
--- cyrus.c.ori Wed Jan 23 00:10:48 2002
+++ cyrus.c Wed Jan 23 00:06:03 2002
@@ -16,7 +16,7 @@
+--+
*/
-/* $Id: cyrus.c,v 1.8 2001/12/11 15:28:59 sebastian Exp $ */
+/* $Id: cyrus.c,v 1.9 2002/01/22 23:34:50 sebastian Exp $ */
#ifdef HAVE_CONFIG_H
#include "config.h"
@@ -64,7 +64,7 @@
ZEND_GET_MODULE(cyrus)
#endif
-static void cyrus_free(zend_rsrc_list_entry *rsrc)
+static void cyrus_free(zend_rsrc_list_entry *rsrc TSRMLS_DC)
{
php_cyrus *conn = (php_cyrus *) rsrc->ptr;
@@ -297,7 +297,7 @@
}
/* Determine the minssf */
- if (argc > 4 && Z_TYPE_PP(z_minssf) != NULL) {
+ if (argc > 4 && Z_TYPE_PP(z_minssf) != IS_NULL) {
convert_to_long_ex(z_minssf);
minssf = Z_LVAL_PP(z_minssf);
}
@@ -306,7 +306,7 @@
}
/* Determine the maxssf */
- if (argc > 5 && Z_TYPE_PP(z_maxssf) != NULL) {
+ if (argc > 5 && Z_TYPE_PP(z_maxssf) != IS_NULL) {
convert_to_long_ex(z_maxssf);
maxssf = Z_LVAL_PP(z_maxssf);
}
@@ -357,7 +357,7 @@
argv[3] = &msgno;
if (call_user_function_ex(EG(function_table), NULL,
callback->function,
- &retval, 4, argv, 0, NULL) ==
FAILURE) {
+ &retval, 4, argv, 0, NULL TSRMLS_CC)
== FAILURE) {
php_error(E_WARNING, "Couldn't call the %s
handler",
callback->trigger);
}
[2002-01-22 18:51:16] [EMAIL PROTECTED]
Hi, I had the same problem!
Here a patch I made who worked so far form me.
What does that mean?
I have absolutely NO C knowledge. Just by comparing the effected line
with similar lines in cyrus.c and other ext files I generated it.
SO I HAVE NO CLUE WHAT I DID !!! - but it compiled.
I haven't installed PHP4 so far and tested the cyrus part.
May be someone with solid C knowledge could check what I did and if
there is a far change that it works.
And here finally the patch:
--- cyrus.c.ori Wed Jan 23 00:10:48 2002
+++ cyrus.c Wed Jan 23 00:06:03 2002
@@ -16,7 +16,7 @@
+--+
*/
-/* $Id: cyrus.c,v 1.8 2001/12/11 15:28:59 sebastian Exp $ */
+/* $Id: cyrus.c,v 1.9 2002/01/22 23:34:50 sebastian Exp $ */
#ifdef HAVE_CONFIG_H
#include "config.h"
@@ -64,7 +64,7 @@
ZEND_GET_MODULE(cyrus)
#endif
-static void cyrus_free(zend_rsrc_list_entry *rsrc)
+static void cyrus_free(zend_rsrc_list_entry *rsrc TSRMLS_DC)
{
php_cyrus *conn = (php_cyrus *) rsrc->ptr;
@@ -297,7 +297,7 @@
}
/* Determine the minssf */
- if (argc > 4 && Z_TYPE_PP(z_minssf) != NULL) {
+ if (argc > 4 && Z_TYPE_PP(z_minssf) != IS_NULL) {
convert_to_long_ex(z_minssf);
minssf = Z_LVAL_PP(z_minssf);
}
@@ -306,7 +306,7 @@
}
/* Determine the maxssf */
- if (argc > 5 && Z_TYPE_PP(z_maxssf) != NULL) {
+ if (argc > 5 && Z_TYPE_PP(z_maxssf) != IS_NULL) {
convert_to_long_ex(z_maxssf);
maxssf = Z_LVAL_PP(z_maxssf);
}
@@ -357,7 +357,7 @@
argv[3] = &msgno;
if (call_user_function_ex(EG(function_table), NULL,
callback->function,
- &retval, 4, argv, 0, NULL) ==
FAILURE) {
+ &retval, 4, argv, 0, NULL TSRMLS_CC)
== FAILURE) {
php_error(E_WARNING, "Couldn't call the %s
handler",
callback->trigger);
}
[2002-01-15 17:18:27] [EMAIL PROTECTED]
Hi,
Vanilla php-4.1.1 src tree,
here's my
Bug #16066:
From: [EMAIL PROTECTED] Operating system: Linux (Debian) PHP version: 4.1.1 PHP Bug Type: Scripting Engine problem Bug description: However without the space it outputs a warning: "Warning: Use of undefined constant PHP - assumed 'PHP'" But this (correctly) doesn't output anything... If you put code after the comment it is worse. This actually dies with a "parser error", but again this works if you use the shorter tag. Outputs "Hello" as expected. The fact that it works when you use "http://bugs.php.net/?id=16066&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16066&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16066&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16066&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16066&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16066&r=support Expected behavior: http://bugs.php.net/fix.php?id=16066&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16066&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16066&r=submittedtwice
Bug #16066 Updated:
ID: 16066 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: Linux (Debian) PHP Version: 4.1.1 New Comment: You say you must have a space after does not report an error, either way something is wrong here, because the behaviour is not consistant for all three of those tokens. I have looked at "Chapter 5. Basic syntax" section of the manual, this explains the use of the However without the space it outputs a warning: "Warning: Use of undefined constant PHP - assumed 'PHP'" But this (correctly) doesn't output anything... If you put code after the comment it is worse. This actually dies with a "parser error", but again this works if you use the shorter tag. Outputs "Hello" as expected. The fact that it works when you use "http://bugs.php.net/?id=16066&edit=1
Bug #16066 Updated:
ID: 16066 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: Linux (Debian) PHP Version: 4.1.1 New Comment: Funny... If (as you claim) this: is not a PHP script, howcome PHP actually prints out "Hello" in this situation? (with no warnings or errors) Is PHP in the habit of running code that is "not PHP script" ? So far both of your reasons for marking this bug as "bogus" have contradicted this example, which was in my original bug report and is something you could easily reproduce yourself. This gives me the impression that either you've not bothered reading my comments, you haven't understood what I'm saying or you think its not important enough to be worth fixing so you're making up lame excuses. Please read this bug report properly and think about it before marking it as "bogus" again. If you don't understand it or can't be bothered with it please refer it to someone who does/can, rather than just closing it. Whatever response you do give, PLEASE make sure it doesn't contradict something I've already explained, that is very frustrating. Previous Comments: [2002-03-15 06:59:01] [EMAIL PROTECTED] PHP will not raise error since it's not PHP script. There is no way to raise error, if it's not a PHP script. [2002-03-15 05:27:51] [EMAIL PROTECTED] You say you must have a space after does not report an error, either way something is wrong here, because the behaviour is not consistant for all three of those tokens. I have looked at "Chapter 5. Basic syntax" section of the manual, this explains the use of the However without the space it outputs a warning: "Warning: Use of undefined constant PHP - assumed 'PHP'" But this (correctly) doesn't output anything... If you put code after the comment it is worse. This actually dies with a "parser error", but again this works if you use the shorter tag. Outputs "Hello" as expected. The fact that it works when you use "http://bugs.php.net/?id=16066&edit=1
Bug #16066 Updated:
ID: 16066 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux (Debian) PHP Version: 4.1.1 New Comment: I totally agree that you is horrible. The reason I found this problem was that I was commenting out a section of HTML using PHP tags. I just stuck in but it confused me when it didn't work. If this space is a requirement it really should be mentioned somewhere in the documentation. I'm going to stick a comment on the "Basic Syntax" section of the manual, where it talks about these tags. I do still think they should all be consistant though. ;o) Previous Comments: [2002-03-15 21:06:49] [EMAIL PROTECTED] Apperently, short tag does not need spaces after open tag :) However, there is nothing wrong and there is nothing we should fix here. i.e. Changing " while is not. [2002-03-15 07:46:38] [EMAIL PROTECTED] Funny... If (as you claim) this: is not a PHP script, howcome PHP actually prints out "Hello" in this situation? (with no warnings or errors) Is PHP in the habit of running code that is "not PHP script" ? So far both of your reasons for marking this bug as "bogus" have contradicted this example, which was in my original bug report and is something you could easily reproduce yourself. This gives me the impression that either you've not bothered reading my comments, you haven't understood what I'm saying or you think its not important enough to be worth fixing so you're making up lame excuses. Please read this bug report properly and think about it before marking it as "bogus" again. If you don't understand it or can't be bothered with it please refer it to someone who does/can, rather than just closing it. Whatever response you do give, PLEASE make sure it doesn't contradict something I've already explained, that is very frustrating. [2002-03-15 06:59:01] [EMAIL PROTECTED] PHP will not raise error since it's not PHP script. There is no way to raise error, if it's not a PHP script. [2002-03-15 05:27:51] [EMAIL PROTECTED] You say you must have a space after does not report an error, either way something is wrong here, because the behaviour is not consistant for all three of those tokens. I have looked at "Chapter 5. Basic syntax" section of the manual, this explains the use of the http://bugs.php.net/16066 -- Edit this bug report at http://bugs.php.net/?id=16066&edit=1
Bug #16066 Updated:
ID: 16066 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux (Debian) PHP Version: 4.1.1 New Comment: How about a decent warning/error when you miss the space then?... At the moment you either get (with all warnings on) "Warning: Use of undefined constant PHP - assumed 'PHP' or it's dies with a "parser error" at line whatever, depending what you have put after the the scanner would not find a delimiter so I assume you'd end up with a token "PHPprint" ? which the parser doesn't understand. I digress... an error message is all I ask. Previous Comments: [2002-03-18 06:26:24] [EMAIL PROTECTED] Goba [2002-03-18 04:07:26] [EMAIL PROTECTED] I totally agree that you is horrible. The reason I found this problem was that I was commenting out a section of HTML using PHP tags. I just stuck in but it confused me when it didn't work. If this space is a requirement it really should be mentioned somewhere in the documentation. I'm going to stick a comment on the "Basic Syntax" section of the manual, where it talks about these tags. I do still think they should all be consistant though. ;o) [2002-03-15 21:06:49] [EMAIL PROTECTED] Apperently, short tag does not need spaces after open tag :) However, there is nothing wrong and there is nothing we should fix here. i.e. Changing " while is not. [2002-03-15 07:46:38] [EMAIL PROTECTED] Funny... If (as you claim) this: is not a PHP script, howcome PHP actually prints out "Hello" in this situation? (with no warnings or errors) Is PHP in the habit of running code that is "not PHP script" ? So far both of your reasons for marking this bug as "bogus" have contradicted this example, which was in my original bug report and is something you could easily reproduce yourself. This gives me the impression that either you've not bothered reading my comments, you haven't understood what I'm saying or you think its not important enough to be worth fixing so you're making up lame excuses. Please read this bug report properly and think about it before marking it as "bogus" again. If you don't understand it or can't be bothered with it please refer it to someone who does/can, rather than just closing it. Whatever response you do give, PLEASE make sure it doesn't contradict something I've already explained, that is very frustrating. [2002-03-15 06:59:01] [EMAIL PROTECTED] PHP will not raise error since it's not PHP script. There is no way to raise error, if it's not a PHP 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/16066 -- Edit this bug report at http://bugs.php.net/?id=16066&edit=1
Bug #16268: Typo in SuperGlobal variable name
From: [EMAIL PROTECTED] Operating system: ALL PHP version: 4.1.0 PHP Bug Type: Documentation problem Bug description: Typo in SuperGlobal variable name On the page at: /manual/en/language.variables.predefined.php where the new superglobals are described, the _COOKIE variable is misspelled and includes an S at the end as _COOKIES -- Edit bug report at http://bugs.php.net/?id=16268&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16268&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16268&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16268&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16268&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16268&r=support Expected behavior: http://bugs.php.net/fix.php?id=16268&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16268&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16268&r=submittedtwice
#49134 [Opn]: posix_times() does not specify units
ID: 49134 Updated by: d...@php.net -Summary: docs for posix_times() does not specify units Reported By: spoon dot reloaded at gmail dot com Status: Open -Bug Type:Documentation problem +Bug Type:POSIX related -PHP Version: Irrelevant +PHP Version: 6 New Comment: The times used in posix_times() are in "clock ticks", however there is currently no way to determine the number of "clock ticks per second" in PHP as it varies per system, so it doesn't translate back into a meaningful number. Reclassifying this as a POSIX-related issue. Can we get the output of sysconf(_SC_CLK_TCK) added as an array element in posix_times()? This would make this function useful. Previous Comments: [2009-08-02 06:54:05] spoon dot reloaded at gmail dot com Description: The posix_times() function returns an array with keys like "utime - user time used by the current process" and "stime - system time used by the current process". But the documentation does not say what units (seconds? microseconds? deciseconds?) are used for the "user time" or "system time". This makes the function completely useless, because one has no idea what the results mean. -- Edit this bug report at http://bugs.php.net/?id=49134&edit=1
#39710 [Fbk->Opn]: getprotobyname is not thread-safe
ID: 39710 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type:Network related PHP Version: 5.2CVS-2006-12-01 (CVS) Previous Comments: [2007-07-27 05:10:31] [EMAIL PROTECTED] And this is only true for PHP 6?! If this applies to PHP 5, adjust the version s/6CVS/5.2CVS/ [2006-12-01 22:57:42] [EMAIL PROTECTED] Description: The PHP functions: getservbyname getservbyport getprotobyname getprotobynumber are not thread safe. -- Edit this bug report at http://bugs.php.net/?id=39710&edit=1
#39710 [Fbk]: getprotobyname is not thread-safe
ID: 39710 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type:Network related PHP Version: 5.2CVS-2006-12-01 (CVS) New Comment: Well, taken from `man getprotobyname` on FreeBSD 6.2: BUGS These functions use a thread-specific data space; if the data is needed for future use, it should be copied before any subsequent calls overwrite it. Only the Internet protocols are currently understood. I believe a race condition still exists in php-src for these functions? Previous Comments: [2007-08-29 11:51:35] [EMAIL PROTECTED] You mean the operating system's functions are not thread-safe? (how to reproduce and what error do you get? :) [2006-12-01 22:57:42] [EMAIL PROTECTED] Description: The PHP functions: getservbyname getservbyport getprotobyname getprotobynumber are not thread safe. -- Edit this bug report at http://bugs.php.net/?id=39710&edit=1
#36812 [Asn]: bind NULL variables generates warning
ID: 36812 Updated by: [EMAIL PROTECTED] Reported By: ce at netage dot bg Status: Assigned Bug Type: PostgreSQL related Operating System: linux PHP Version: 5.1.3RC1 Assigned To: helly New Comment: This happens because pg_execute() modifies the array values, so $temp1 gets passed a NULL initially, then $temp1 is converted to a string which is why the second time it is passed it fails to execute. This can be demonstrated by doing var_dump($temp1); before and after the pg_execute() statement. I don't claim to know PHP internals, but perhaps the fact that it uses convert_to_string() instead of convert_to_string_ex() is the cause? Previous Comments: [2006-09-26 22:30:01] [EMAIL PROTECTED] Assigned to the maintainer. [2006-03-23 09:58:44] ce at netage dot bg check the workarround and see how an array of $param_list = array(null, null, null); does NOT generate any error, actually working as expected (so the problem is not at the integer type of the column, because it has the right to be NULL) [2006-03-22 18:19:30] [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 You declare the parameter is being of type INT and then put NULL into it. Is it any wonder PostgreSQL generates an error? [2006-03-21 12:38:16] ce at netage dot bg Description: when binding explicit null value there is no problem (see the workarround), but, when the null value is from variable there is a problem (the example is stupid, but is the simplest one representing the problem) Reproduce code: --- CREATE TABLE nullproblem (i integer); Expected result: nothing special Actual result: -- Warning: pg_execute(): Query failed: ERROR: invalid input syntax for integer: "" in test.php on line 10 -- Edit this bug report at http://bugs.php.net/?id=36812&edit=1
#36969 [Asn->Bgs]: pg_query_params() fails for integer column with 'INSERT INTO..SELECT DISTINCT'
ID: 36969
Updated by: [EMAIL PROTECTED]
Reported By: alan dot harder at sun dot com
-Status: Assigned
+Status: Bogus
Bug Type: PostgreSQL related
Operating System: Debian
PHP Version: 5.1.5
Assigned To: helly
New Comment:
This is not a bug in PHP itself. As you can see below, the same thing
happens using psql (and I'm using PostgreSQL 8.2beta2). Perhaps you
should contact the Postgres guys, or perhaps distinct simply needs you
to be more specific about the type it needs to distinguish against?
$1::int works with distinct, for example.
testdb=# prepare blah as insert into test select distinct $1;
ERROR: column "i" is of type integer but expression is of type text
HINT: You will need to rewrite or cast the expression.
testdb=# prepare blah as insert into test select $1;
PREPARE
testdb=#
Previous Comments:
[2006-09-26 22:27:47] [EMAIL PROTECTED]
Assigned to the maintainer.
[2006-08-30 18:50:24] alan dot harder at sun dot com
Tested on PHP 5.1.5.. same result.
[2006-04-04 17:00:24] alan dot harder at sun dot com
Description:
parameter given as integer but treated as text with particular sql
syntax. remove "distinct" from the sql and it works.
Tested with PHP 5.1.2 and PHP 5.1.3-RC2
pg_version output:
array(3) { ["client"]=> string(5) "8.1.2" ["protocol"]=> int(3)
["server"]=> string(6) "7.4.11" }
Reproduce code:
---
First in psql:
create table test (val integer);
Test code:
Expected result:
OK
Actual result:
--
Warning: pg_query_params() [function.pg-query-params]: Query failed:
ERROR: column "val" is of type integer but expression is of type text
HINT: You will need to rewrite or cast the expression. in
/usr/home/mindless/public_html/pgtest.php on line 5
ERROR: column "val" is of type integer but expression is of type text
HINT: You will need to rewrite or cast the expression.
--
Edit this bug report at http://bugs.php.net/?id=36969&edit=1
Bug #16918: no php_mssql.dll support -> mssql_pconnect() not recognized
From: [EMAIL PROTECTED] Operating system: Win2000 PHP version: 4.0CVS-2002-04-29 PHP Bug Type: IIS related Bug description: no php_mssql.dll support -> mssql_pconnect() not recognized Installed PHP4.0 on Win200 platform in C:\PHP There is one .dll (php4ts.dll) only... It appears that the built in php_mssql.dll support is not working very well out of the box ?? I continue to get the following error: Fatal error: Call to undefined function: mssql_pconnect() in C:\Inetpub\wwwroot\HappySnappers\db_mssql.inc on line 37 I have tried most everything I can think of to no avail. Any suggestions on how to get the supposedly built in MSSQL libray support ?? -- Edit bug report at http://bugs.php.net/?id=16918&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16918&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16918&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16918&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16918&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16918&r=support Expected behavior: http://bugs.php.net/fix.php?id=16918&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16918&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16918&r=submittedtwice
#26657 [NEW]: exec() strange behaviour
From: dave at theholdens dot net
Operating system: Win2K Server
PHP version: 4.3.4
PHP Bug Type: *General Issues
Bug description: exec() strange behaviour
Description:
I have been trying to use exec() to run a legacy 16-bit DOS .EXE program
to peform a complex calculatation that involves looking stuff up in dbase
tables. It refuses to work. I have checked everything including
permissions, paths, php.ini Safe Mode settings, etc. All of the security
is basically turned off. The really curious behaviour is that my exec
function call works fine for system commands like ipconfig and dir, but
does not work for my DOS program, even when I move it into the
windows\system32 directory beside all of the commands that DO work. I
have checked that the DOS program is sending back appropriate return
codes. The DOS program works fine when I type in the exact string being
passed to the shell from the command line.
The same php code ran fine on a RedHat 8.x box, but broke when moved to
Windows 2K3 server.
Reproduce code:
---
// this works fine
$output = exec("cmd /C ipconfig", $out_lines, $ret_code);
for($ctr=0; $ctr < count($out_lines); $ctr++)
echo $out_lines[$ctr] . "";
// this does not work (and grep.com IS copied to win\s32 dir and given ALL
permissions for EVERYONE)
$output = exec("cmd /C c:\\windows\\system32\\grep -i \"safe\"
c:\\windows\\php.ini", $out_lines, $ret_code);
for($ctr=0; $ctr < count($out_lines); $ctr++)
echo $out_lines[$ctr] . "";
Expected result:
The "works fine" code shows the ipconfig output stream exactly as expected
and $ret_code contains 0.
Actual result:
--
The "doesn't work" code shows nothing. The $out_lines array is empty and
$ret_code contains 1. No errors appear in the log or the web page, even
though error logging is turned on for both.
--
Edit bug report at http://bugs.php.net/?id=26657&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26657&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26657&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26657&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26657&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26657&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26657&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26657&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26657&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26657&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26657&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26657&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26657&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26657&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26657&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26657&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26657&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26657&r=float
#26657 [Fbk->Csd]: exec() strange behaviour
ID: 26657
User updated by: dave at theholdens dot net
Reported By: dave at theholdens dot net
-Status: Feedback
+Status: Closed
Bug Type: Program Execution
Operating System: Win2K Server
PHP Version: 4.3.4
New Comment:
Upgrading Apache to 2.0.48 fixed the problem.
Previous Comments:
[2003-12-18 03:28:47] [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
And are you aware that you're now calling com 2 times?
(exec() in PHP does 'cmd /c' itself)
[2003-12-17 17:12:47] dave at theholdens dot net
Description:
I have been trying to use exec() to run a legacy 16-bit DOS .EXE
program to peform a complex calculatation that involves looking stuff
up in dbase tables. It refuses to work. I have checked everything
including permissions, paths, php.ini Safe Mode settings, etc. All of
the security is basically turned off. The really curious behaviour is
that my exec function call works fine for system commands like ipconfig
and dir, but does not work for my DOS program, even when I move it into
the windows\system32 directory beside all of the commands that DO work.
I have checked that the DOS program is sending back appropriate return
codes. The DOS program works fine when I type in the exact string
being passed to the shell from the command line.
The same php code ran fine on a RedHat 8.x box, but broke when moved to
Windows 2K3 server.
Reproduce code:
---
// this works fine
$output = exec("cmd /C ipconfig", $out_lines, $ret_code);
for($ctr=0; $ctr < count($out_lines); $ctr++)
echo $out_lines[$ctr] . "";
// this does not work (and grep.com IS copied to win\s32 dir and given
ALL permissions for EVERYONE)
$output = exec("cmd /C c:\\windows\\system32\\grep -i \"safe\"
c:\\windows\\php.ini", $out_lines, $ret_code);
for($ctr=0; $ctr < count($out_lines); $ctr++)
echo $out_lines[$ctr] . "";
Expected result:
The "works fine" code shows the ipconfig output stream exactly as
expected and $ret_code contains 0.
Actual result:
--
The "doesn't work" code shows nothing. The $out_lines array is empty
and $ret_code contains 1. No errors appear in the log or the web page,
even though error logging is turned on for both.
--
Edit this bug report at http://bugs.php.net/?id=26657&edit=1
#22599 [NEW]: apxs requires -bE parameter on AIX
From: dave at zalasta dot com
Operating system: AIX 4.3.3
PHP version: 4.3.1
PHP Bug Type: Apache related
Bug description: apxs requires -bE parameter on AIX
When attempting to run (as root)
configure
--with-mysql
--with-apxs=/usr/HTTPServer/bin/apxs
the configure script fails with "cannot find apxs" when apxs exists. It
appears that apxs on AIX 4.3.3 requires a .exp file to execute, which is
passed to apxs via a -bE parameter. There is no .exp file in the source
distribution of php 4.3.1... could this be the problem?
config.log follows:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
configure:1539: checking for Cygwin environment
configure:1555: cc -c conftest.c 1>&5
./configure[1554]: cc: not found
configure: failed program was:
#line 1544 "configure"
#include "confdefs.h"
int main() {
#ifndef __CYGWIN__
#define __CYGWIN__ __CYGWIN32__
#endif
return __CYGWIN__;
; return 0; }
configure:1572: checking for mingw32 environment
configure:1584: cc -c conftest.c 1>&5
./configure[1583]: cc: not found
configure: failed program was:
#line 1577 "configure"
#include "confdefs.h"
int main() {
return __MINGW32__;
; return 0; }
configure:1603: checking for working sed
configure:1726: checking host system type
configure:1815: checking for gcc
configure:1928: checking whether the C compiler (gcc ) works
configure:1944: gcc -o conftestconftest.c 1>&5
configure:1970: checking whether the C compiler (gcc ) is a
cross-compiler
configure:1975: checking whether we are using GNU C
configure:1984: gcc -E conftest.c
configure:2003: checking whether gcc accepts -g
configure:2036: checking whether gcc and cc understand -c and -o together
configure:2051: gcc -c conftest.c -o conftest.o 1>&5
configure:2052: gcc -c conftest.c -o conftest.o 1>&5
configure:2057: cc -c conftest.c 1>&5
./configure[2056]: cc: not found
configure:2087: checking how to run the C preprocessor
configure:2108: gcc -E conftest.c >/dev/null 2>conftest.out
configure:2168: checking for AIX
configure:2195: checking if compiler supports -R
configure:2210: gcc -o conftestconftest.c -R /usr/lib 1>&5
gcc: unrecognized option `-R'
ld: 0711-168 SEVERE ERROR: Input file: /usr/lib
Input files must be regular files.
collect2: ld returned 12 exit status
configure: failed program was:
#line 2203 "configure"
#include "confdefs.h"
int main() {
; return 0; }
configure:2228: checking if compiler supports -Wl,-rpath,
configure:2243: gcc -o conftestconftest.c -Wl,-rpath,/usr/lib 1>&5
ld: 0706-012 The -p flag is not recognized.
ld: 0706-012 The -a flag is not recognized.
ld: 0706-012 The -t flag is not recognized.
ld: 0706-012 The -h flag is not recognized.
collect2: ld returned 255 exit status
configure: failed program was:
#line 2236 "configure"
#include "confdefs.h"
int main() {
; return 0; }
configure:2268: checking for ranlib
configure:2296: checking whether ln -s works
configure:2321: checking for gawk
configure:2321: checking for mawk
configure:2321: checking for nawk
configure:2355: checking for bison
configure:2355: checking for byacc
configure:2399: checking for flex
configure:2433: checking for yywrap in -ll
configure:2452: gcc -o conftestconftest.c -ll 1>&5
configure:2476: checking lex output file root
configure:2497: checking whether yytext is a pointer
configure:2516: gcc -o conftestconftest.c -ll 1>&5
configure:3207: conflicting types for `yytext'
configure:2566: previous declaration of `yytext'
configure: failed program was:
#line 2509 "configure"
#include "confdefs.h"
# include
# include
# include
# include
# define U(x) ((x)&0377)
# define NCH 256
# define NLSTATE yyprevious=YYNEWLINE
# define BEGIN yybgin = yysvec + 1 +
# define INITIAL 0
# define YYLERR yysvec
# define YYSTATE (yyestate-yysvec-1)
# define YYOPTIM 1
# define YYLMAX 2000
#ifdef __cplusplus
int yylook(void);
extern "C" int yywrap(void), yyless(int), yyreject(void);
#endif /* __cplusplus */
#if defined(__cplusplus) && defined(_CPP_IOSTREAMS)
# include
# define output(c) (*yyout) << ((unsigned char) c)
# define input()
(((yytchar=yysptr>yysbuf?U(*--yysptr):yyin->get())==10?(yylineno++,yytchar):yytchar)==EOF?0:yytchar)
# define ECHO (*yyout) << yytext
istream *yyin = &cin;
ostream *yyout = &cout;
#else
# define output(c) putc(c,yyout)
# define input()
(((yytchar=yysptr>yysbuf?U(*--yysptr):getc(yyin))==10?(yylineno++,yytchar):yytchar)==EOF?0:yytchar)
# define ECHO fprintf(yyout, "%S",yywtext)
FILE *yyin = NULL, *yyout = NULL;
#endif /* defined(__cplusplus) && defined(_CPP_IOSTREAMS) */
# define unput(c) {yytchar=
(c);if(yytchar=='\n')yylineno--;*yysptr++=yytchar;}
#22599 [Csd->Opn]: apxs requires -bE parameter on AIX
ID: 22599
User updated by: dave at zalasta dot com
Reported By: dave at zalasta dot com
-Status: Closed
+Status: Open
Bug Type: Apache related
Operating System: AIX 4.3.3
PHP Version: 4.3.1
New Comment:
Hi again
Tried both php4 and php5 snaps 200303092230, and still the same
error could it be the path to perl that is the problem? perl5 is
referenced by two symlinks, one in usr/bin, and one in /usr/lib, both
named "perl". /usr/bin is in my path.
If I type...
cd /usr/HTTPServer/bin
perl ./apxs
I get the help prompt.
Any help?
Cheers
Dave
Previous Comments:
[2003-03-08 11:07:43] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-03-07 19:34:57] dave at zalasta dot com
When attempting to run (as root)
configure
--with-mysql
--with-apxs=/usr/HTTPServer/bin/apxs
the configure script fails with "cannot find apxs" when apxs exists. It
appears that apxs on AIX 4.3.3 requires a .exp file to execute, which
is passed to apxs via a -bE parameter. There is no .exp file in the
source distribution of php 4.3.1... could this be the problem?
config.log follows:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
configure:1539: checking for Cygwin environment
configure:1555: cc -c conftest.c 1>&5
./configure[1554]: cc: not found
configure: failed program was:
#line 1544 "configure"
#include "confdefs.h"
int main() {
#ifndef __CYGWIN__
#define __CYGWIN__ __CYGWIN32__
#endif
return __CYGWIN__;
; return 0; }
configure:1572: checking for mingw32 environment
configure:1584: cc -c conftest.c 1>&5
./configure[1583]: cc: not found
configure: failed program was:
#line 1577 "configure"
#include "confdefs.h"
int main() {
return __MINGW32__;
; return 0; }
configure:1603: checking for working sed
configure:1726: checking host system type
configure:1815: checking for gcc
configure:1928: checking whether the C compiler (gcc ) works
configure:1944: gcc -o conftestconftest.c 1>&5
configure:1970: checking whether the C compiler (gcc ) is a
cross-compiler
configure:1975: checking whether we are using GNU C
configure:1984: gcc -E conftest.c
configure:2003: checking whether gcc accepts -g
configure:2036: checking whether gcc and cc understand -c and -o
together
configure:2051: gcc -c conftest.c -o conftest.o 1>&5
configure:2052: gcc -c conftest.c -o conftest.o 1>&5
configure:2057: cc -c conftest.c 1>&5
./configure[2056]: cc: not found
configure:2087: checking how to run the C preprocessor
configure:2108: gcc -E conftest.c >/dev/null 2>conftest.out
configure:2168: checking for AIX
configure:2195: checking if compiler supports -R
configure:2210: gcc -o conftestconftest.c -R /usr/lib 1>&5
gcc: unrecognized option `-R'
ld: 0711-168 SEVERE ERROR: Input file: /usr/lib
Input files must be regular files.
collect2: ld returned 12 exit status
configure: failed program was:
#line 2203 "configure"
#include "confdefs.h"
int main() {
; return 0; }
configure:2228: checking if compiler supports -Wl,-rpath,
configure:2243: gcc -o conftestconftest.c -Wl,-rpath,/usr/lib
1>&5
ld: 0706-012 The -p flag is not recognized.
ld: 0706-012 The -a flag is not recognized.
ld: 0706-012 The -t flag is not recognized.
ld: 0706-012 The -h flag is not recognized.
collect2: ld returned 255 exit status
configure: failed program was:
#line 2236 "configure"
#include "confdefs.h"
int main() {
; return 0; }
configure:2268: checking for ranlib
configure:2296: checking whether ln -s works
configure:2321: checking for gawk
configure:2321: checking for mawk
configure:2321: checking for nawk
configure:2355: checking for bison
configure:2355: checking for byacc
configure:2399: checking for flex
configure:2433: checking for yywrap in -ll
configure:2452: gcc -o conftestconftest.c -ll 1>&5
configure:2476: checking lex output file root
configure:2497: checking whether yytext is a pointer
configure:2516: gcc -o conftestconftest.c -ll 1>&5
configure:3207: conflicting types for `yytext'
configure:2566: previous declaration of `yytext'
configure: failed program was:
#line 2509 &
#22599 [Bgs->Opn]: apxs requires -bE parameter on AIX
ID: 22599
User updated by: dave at zalasta dot com
Reported By: dave at zalasta dot com
-Status: Bogus
+Status: Open
-Bug Type: Apache related
+Bug Type: *Configuration Issues
Operating System: AIX 4.3.3
-PHP Version: 4.3.1
+PHP Version: php5-200303092230
New Comment:
Solved apxs problem incorrect directive in apxs... pointing to
wrong location for perl.
New problem when running ./configure, get to:
checking for mysqli support ... no
then
-l
./configure[53628]: syntax error at line 53629: 'else' expected.
Over to you .
Previous Comments:
[2003-03-09 18:29:32] [EMAIL PROTECTED]
This sounds more like bad install of apache.
How did you install apache? What version?
Are you sure it actually supports DSOs?
What does this output:
# /usr/HTTPServer/bin/apxs -q CFLAGS
And what about:
# ls -l /usr/HTTPServer/bin/apxs
You might just not have execute rights on the file
for the user as you're running configure as.
Try doing it as root.
As this is really not PHP bug at all, I'm bogusing this.
Please ask further support questions on appropriate mailing
list. See www.php.net/support.php for more info.
[2003-03-09 18:15:57] dave at zalasta dot com
Hi again
Tried both php4 and php5 snaps 200303092230, and still the same
error could it be the path to perl that is the problem? perl5 is
referenced by two symlinks, one in usr/bin, and one in /usr/lib, both
named "perl". /usr/bin is in my path.
If I type...
cd /usr/HTTPServer/bin
perl ./apxs
I get the help prompt.
Any help?
Cheers
Dave
[2003-03-08 11:07:43] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
----
[2003-03-07 19:34:57] dave at zalasta dot com
When attempting to run (as root)
configure
--with-mysql
--with-apxs=/usr/HTTPServer/bin/apxs
the configure script fails with "cannot find apxs" when apxs exists. It
appears that apxs on AIX 4.3.3 requires a .exp file to execute, which
is passed to apxs via a -bE parameter. There is no .exp file in the
source distribution of php 4.3.1... could this be the problem?
config.log follows:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
configure:1539: checking for Cygwin environment
configure:1555: cc -c conftest.c 1>&5
./configure[1554]: cc: not found
configure: failed program was:
#line 1544 "configure"
#include "confdefs.h"
int main() {
#ifndef __CYGWIN__
#define __CYGWIN__ __CYGWIN32__
#endif
return __CYGWIN__;
; return 0; }
configure:1572: checking for mingw32 environment
configure:1584: cc -c conftest.c 1>&5
./configure[1583]: cc: not found
configure: failed program was:
#line 1577 "configure"
#include "confdefs.h"
int main() {
return __MINGW32__;
; return 0; }
configure:1603: checking for working sed
configure:1726: checking host system type
configure:1815: checking for gcc
configure:1928: checking whether the C compiler (gcc ) works
configure:1944: gcc -o conftestconftest.c 1>&5
configure:1970: checking whether the C compiler (gcc ) is a
cross-compiler
configure:1975: checking whether we are using GNU C
configure:1984: gcc -E conftest.c
configure:2003: checking whether gcc accepts -g
configure:2036: checking whether gcc and cc understand -c and -o
together
configure:2051: gcc -c conftest.c -o conftest.o 1>&5
configure:2052: gcc -c conftest.c -o conftest.o 1>&5
configure:2057: cc -c conftest.c 1>&5
./configure[2056]: cc: not found
configure:2087: checking how to run the C preprocessor
configure:2108: gcc -E conftest.c >/dev/null 2>conftest.out
configure:2168: checking for AIX
configure:2195: checking if compiler supports -R
configure:2210: gcc -o conftestconftest.c -R /usr/lib 1>&5
gcc: unrecognized option `-R'
ld: 0711-168 SEVERE ERROR: Input file: /usr/lib
Input files must be regular files.
collect2: ld returned 12 exit status
configure: failed program was:
#line 2203 "configure"
#include "confdefs.h"
int main() {
; return 0; }
configure:2228: checking if compiler supports
#22642 [NEW]: After saving a session var in a var, nulling the session var clears the 2nd var
From: dave at orangechicken dot com Operating system: Linux / Apache 1.3.27 PHP version: 4.3.1 PHP Bug Type: Session related Bug description: After saving a session var in a var, nulling the session var clears the 2nd var OK, the summary was too short to concisely enter what I mean. Here's the real version: After assigning a stored $_SESSION var to another variable, assigning null to the $_SESSION var clears the other variable too. This worked before 4.3.1 (possibly occurred in 4.3.0 - we skipped from 4.2.7 to 4.3.1). Here's a snippet where the problem occurs. $_SESSION[ 'login_redirect' ] contains the value 'checkout.php'. $redirect = $_SESSION[ 'login_redirect' ]; echo $redirect; // outputs checkout.php $_SESSION[ 'login_redirect' ] = null; echo $redirect; // outputs Here's the configure string './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-xml' '--enable-bcmath' '--enable-calendar' '--with-curl' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-imap' '--with-imap-ssl' '--with-kerberos' '--with-mcrypt' '--enable-magic-quotes' '--with-mysql' '--with-pear' '--enable-xslt' '--with-xslt-sablot' '--enable-sockets' '--enable-track-vars' '--with-ttf' '--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--enable-versioning' '--with-zlib' -- Edit bug report at http://bugs.php.net/?id=22642&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22642&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22642&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22642&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22642&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22642&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22642&r=support Expected behavior: http://bugs.php.net/fix.php?id=22642&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22642&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22642&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22642&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22642&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22642&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22642&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22642&r=gnused
#22642 [Fbk->Csd]: After saving a session var in a var, nulling the session var clears the 2nd var
ID: 22642 User updated by: dave at orangechicken dot com Reported By: dave at orangechicken dot com -Status: Feedback +Status: Closed Bug Type: Session related Operating System: Linux / Apache 1.3.27 PHP Version: 4.3.1 New Comment: I'm uber-tarded. I found the solution an hour later or so (and it's the same one suggested above). I used an .htaccess file to turn register_globals off. I had been working in my dev environment so long (with register_globals off in php.ini) that I didn't even think about that when I moved to the live environment (which defaults to on). My bad. Case closed. Previous Comments: [2003-03-11 21:07:22] [EMAIL PROTECTED] Please provide a short but complete example script. And is register_globals=off ? And what about session.bug_compat_42 and session.bug_compat_warn? Put 'error_reporting(E_ALL);' as first line in your script, you propably get some errors.. ---- [2003-03-11 15:54:35] dave at orangechicken dot com OK, the summary was too short to concisely enter what I mean. Here's the real version: After assigning a stored $_SESSION var to another variable, assigning null to the $_SESSION var clears the other variable too. This worked before 4.3.1 (possibly occurred in 4.3.0 - we skipped from 4.2.7 to 4.3.1). Here's a snippet where the problem occurs. $_SESSION[ 'login_redirect' ] contains the value 'checkout.php'. $redirect = $_SESSION[ 'login_redirect' ]; echo $redirect; // outputs checkout.php $_SESSION[ 'login_redirect' ] = null; echo $redirect; // outputs Here's the configure string './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-xml' '--enable-bcmath' '--enable-calendar' '--with-curl' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-imap' '--with-imap-ssl' '--with-kerberos' '--with-mcrypt' '--enable-magic-quotes' '--with-mysql' '--with-pear' '--enable-xslt' '--with-xslt-sablot' '--enable-sockets' '--enable-track-vars' '--with-ttf' '--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--enable-versioning' '--with-zlib' -- Edit this bug report at http://bugs.php.net/?id=22642&edit=1
#20449 [Com]: sessions randomly fail
ID: 20449 Comment by: dave at flitsservice dot nl Reported By: josh at zebotech dot com Status: Open Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.4.0-dev New Comment: * PHP Version 4.2.2 (and 4.1.1) * Apache 2.0.40 (and 1.3.23) * Windows NT 5.1 build 2600 (Windows XP sp1) Allright, I experience this problem also! (thnx Google). It drives me mad, I already did a downgrade to PHP v4.1.1 without succes. I experience the same situation as jpmarray, the page looks like it loads, I get some HTML code and a part of my page is displayed... Suddenly it breaks off the output showing some unfinished HTML code and a "Page cannot be displayed" occurs. And I'm talking of the well known phpinfo.php now! The strange thing which someone else mentioned also here, is that it works perfectly well with all non-IE related browsers. I tested it for example with Mozilla 1.0 and everything is working fine. And now comes the strange part. I have another server here, running exactly the same OS (Windows NT 5.1 build 2600) and exactly the same installation and php.ini file (version 4.1.1) and that is working perfectly well. The only difference is the Apache server version; 1.3.23 And I don't want to downgrade Apache unless I have too... Oh and another thing, I tried to run phpinfo.php on different machines, all resulting with the same problem. No go with IE and Mozilla and Opera 7 everything looks OK... But while I test this when I'm writing this now, I see that it isn't OK either with other browsers... It does not result in a "page cannot be found" error but it just unfinishes the page ending. This looks like it's doing it at random... Sometimes stopping earlier and sometimes near the end of the output... Very strange! Nothing is wrong with my php maximum execution time or something. Remember that I have two different servers with exactly the same PHP installation... Maybe I'll try an Apache downgrade to exclude some things out tomorrow... First I'll get some sleep, luckily this is less critical than the problem of Josh... Dave Lolkes de Beer The Netherlands Previous Comments: [2003-01-31 14:57:30] jpmurray at hxti dot com Hello all, * PHP Version 4.2.3 * Apache 1.3.27 * Linux * config: ./configure' '--with-apxs' '--with-oci8=/usr/local/oracle/m01/app/oracle/product/8.1.7/' '--with-openssl' '--with-curl' '--with-mysql' I'm having this problem every day, and can reproduce at will. Extremely frustrating. For me it only occurs upon (successful) login to my site. Instead of going to the php index, I get a "Page cannot be displayed". I'm using non-cookie sessions managed by an Oracle database. Once I am in, past the login, the error never occurs however. It seems only to be a problem when the session is first initialized via session_start(). After this, I pass the sid via the URL, and its subsequently checked by the target script against the oracle db for authenticity- No problems at all there. Does anybody else see this problem occur only upon doing things such as logging in? Thanks, J. Murray HX Technologies [2003-01-08 11:45:20] phpBug20449 at rehner dot net Further testing shows that on Windows 2000 Server with Identical Configurations as the Windows 2000 Pro (I did diffs to be sure) reveals: Win2000Server 2 Processor- 2 failues in an estimates 300,000 tests. Win2000Server 4 processor - 0 failures in 1000 tests (Just started running this one.) Basically I had everyone in the office run the test against the 2 Processor system at the same time. Only 2 failures in that many requests I can live with. So is it more of an issue on less capable systems? [2003-01-08 01:52:58] josh at zebotech dot com interesting. However, I switched my session manager to a dbase function and it still died. How would file locking effect that? I'm interested in the fact though that you can actually witness the bug first hand. I only saw that it was happening. However, I could never get the thing to happen to me. Also, since I have gone to my own session code without using php's built in sessions, I don't have problems at all anymore. Josh [2003-01-08 01:19:06] bug20449 at rehner dot net My script will fail in as short as 1 request or over 1000 requests. I did set session.gc_probability = 0 but still fails. -Ryan [2003-01-08 01:13:53] phpBug20449 at rehner dot net I CAN REPRODUCE THIS BUG!!! Sort ofÂ… I too had my software w
#23935 [Csd->Opn]: array_key_exists no longer juggles types correctly
ID: 23935
User updated by: dave at codewhore dot org
Reported By: dave at codewhore dot org
-Status: Closed
+Status: Open
Bug Type: Arrays related
Operating System: Linux 2.4
PHP Version: 5CVS-2003-05-31 (dev)
Assigned To: sterling
New Comment:
Hi Sterling:
I think there's a remaining (related) problem, this time with array
keys that are strings. I've enclosed a test case.
0);
var_dump($f);
var_dump(array_key_exists(7, $f));
/* This doesn't */
$f = array_flip(array('7'));
var_dump($f);
var_dump(array_key_exists(7, $f));
?>
On PHP 5, I get:
array(1) {
[7]=>
int(0)
}
bool(true)
array(1) {
["7"]=>
int(0)
}
bool(false)
On PHP 4 I get:
array(1) {
[7]=>
int(0)
}
bool(true)
array(1) {
[7]=>
int(0)
}
bool(true)
Thanks in advance,
- Dave
Previous Comments:
[2003-06-05 11:16:09] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
fixed in cvs, thanks.
----
[2003-05-31 23:12:32] dave at codewhore dot org
Hi:
The following script produces different output with PHP 5 HEAD than it
does with the PHP 4.3 stable branch:
With PHP 4.3 stable, I get:
bool(true)
With PHP 5 HEAD, I get:
bool(false)
It appears that PHP 5 HEAD is missing the call to HANDLE_NUMERIC() in
zend_hash_exists (Zend/zend_hash.c). The ZE2 changelog shows that it
was moved:
move HANDLE_NUMERIC() from the hash table
implementation upstream to the places that
actually need to use it.
But I'm unable to figure out where the equivalent functionality was
added back. Am I missing something?
Thanks in advance,
- Dave
--
Edit this bug report at http://bugs.php.net/?id=23935&edit=1
#23935 [Opn]: array_key_exists no longer juggles types correctly
ID: 23935
User updated by: dave at codewhore dot org
Reported By: dave at codewhore dot org
Status: Open
Bug Type: Arrays related
Operating System: Linux 2.4
PHP Version: 5CVS-2003-05-31 (dev)
Assigned To: sterling
New Comment:
I should clarify that it looks like the problem is in array_flip, not
array_key_exists. Is it okay to keep this here?
Previous Comments:
[2003-06-06 16:07:23] dave at codewhore dot org
Hi Sterling:
I think there's a remaining (related) problem, this time with array
keys that are strings. I've enclosed a test case.
0);
var_dump($f);
var_dump(array_key_exists(7, $f));
/* This doesn't */
$f = array_flip(array('7'));
var_dump($f);
var_dump(array_key_exists(7, $f));
?>
On PHP 5, I get:
array(1) {
[7]=>
int(0)
}
bool(true)
array(1) {
["7"]=>
int(0)
}
bool(false)
On PHP 4 I get:
array(1) {
[7]=>
int(0)
}
bool(true)
array(1) {
[7]=>
int(0)
}
bool(true)
Thanks in advance,
- Dave
[2003-06-05 11:16:09] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
fixed in cvs, thanks.
----
[2003-05-31 23:12:32] dave at codewhore dot org
Hi:
The following script produces different output with PHP 5 HEAD than it
does with the PHP 4.3 stable branch:
With PHP 4.3 stable, I get:
bool(true)
With PHP 5 HEAD, I get:
bool(false)
It appears that PHP 5 HEAD is missing the call to HANDLE_NUMERIC() in
zend_hash_exists (Zend/zend_hash.c). The ZE2 changelog shows that it
was moved:
move HANDLE_NUMERIC() from the hash table
implementation upstream to the places that
actually need to use it.
But I'm unable to figure out where the equivalent functionality was
added back. Am I missing something?
Thanks in advance,
- Dave
--
Edit this bug report at http://bugs.php.net/?id=23935&edit=1
#18600 [Com]: Unable to create Java Virtual Machine
ID: 18600 Comment by: dave at unicon dot net Reported By: nalves at equifax dot com dot br Status: Open Bug Type: Java related Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: Has anything been resolved for this usiong the non-cgi approach? I have found something I did not see in other comments. It seems that I get the fatal error after a set amount of seconds. Maybe due to some time out? Thanks Previous Comments: [2003-05-24 07:40:55] asifrrana at hotmail dot com Has anyone found a good (not using cgi-bin) resolution to this problem yet? I just downloaded the latest release 4.3.2 with JDK1.4.0 on Windows 2000 and I am still getting the same error "Fatal error: Unable to create Java Virtual Machine" [2003-05-22 04:11:11] Mike at 123456 dot net Hi everybody, I experience the problem of the "Unable to create Java Virtual Machine", on a Windows 2000, with easyphp, after some search, my conclusion is that you couldn't use (for the moment) php as a module in Apache, you must for that use it in cgi mode (I tried it and it work fine, and change from module to cgi mode doesn't affect usage of PHP). My configuration is : Windows 2000 Apache 2.0.45 J2SDK 1.4.1_02 PHP 4.3.2 RC3 You must install J2SK, Apache, and then php (the tutorial indicate how to install in cgi mode), you can go to the following adress for installation (a very good tutorial) : http://hotwired.lycos.com/webmonkey/00/44/index4a_page8.html?tw=programming after that just configure you php.ini with the following values : [Java] extension=php_java.dll java.home = C:\j2sdk1.4.1_02\jre\bin java.library = C:\j2sdk1.4.1_02\jre\bin\server\jvm.dll java.library.path = C:\php4\extensions java.class.path = "C:\php4\extensions\php_java.jar;C:\MyClasses;" Don't forget to affect the extension_dir value like : extension_dir=C:\php4\extensions And now it's work. [2003-05-16 10:37:30] fj at hilab dot it I personally have experienced the same problem with the 1.4.0_02 SDK externally connected to php4.3.1 under Win2K. I had very frequently the aforementioned 'Unable to create Java Virtual Machine' error and after a number of tests I discovered that such error never happened the first time I restarted the php engine by restarting the Apache server. This made me think that the JVM is left in an abnormal state after the php interpreter exits the page. For this reason I inserted an explicit call to the System.exit(0) at the very end of the page and this solved all the problems! The only side effect is that now it is mandatory to call the flush() php function, or the page will not be completely shown... [2003-05-07 16:35:51] db_farr at excite dot com isnt there a way to close the instantiated class and release the resources? like the unset() command seems that would clear any resource retention problem and allow php to reinstantiate the jvm. [2003-05-01 14:35:34] sohelnmerchant at yahoo dot com Hi, I am using PHP as a SAPI modlue in Apache (as it was recommended in the readme file that its unsafe to use PHP in CGI mode) on windows. Whenever I try to use a java class I keep on getting this problem "Unable to create Java Virtual Machine". Some people have sggested to use CGI version instead of SAPI. But I dont wanna use it for the reasons mentioned above. I am wondering, if there exist any patch which can eliminate this problem. Thanks, Sohel Merchant. 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/18600 -- Edit this bug report at http://bugs.php.net/?id=18600&edit=1
#23922 [NEW]: With assert(string): $this unavailable inside of eval() code
From: dave at codewhore dot org
Operating system: Linux 2.4
PHP version: 5CVS-2003-05-31 (dev)
PHP Bug Type: Scripting Engine problem
Bug description: With assert(string): $this unavailable inside of eval() code
Hi:
Given the following script, which uses assert to eval() a string that
references the current class instance:
foo == 1'); }
function as_expr()
{ assert($this->foo == 1); }
}
$foo = new foo();
$foo->as_expr();
$foo->as_string();
?>
PHP 4.3-cvs executes it correctly, but PHP 5.0-cvs with ZE2 fails:
Fatal error: Using $this when not in object context in
/home/dave/test.php(8) : assert code on line 1
Is this expected behavior? More specifically, is $this no longer available
inside of an eval() on ZE2?
Thanks in advance,
- Dave
--
Edit bug report at http://bugs.php.net/?id=23922&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=23922&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=23922&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=23922&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=23922&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=23922&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=23922&r=support
Expected behavior: http://bugs.php.net/fix.php?id=23922&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=23922&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=23922&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=23922&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=23922&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=23922&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=23922&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=23922&r=gnused
#23925 [NEW]: ZE2 crashes when switch() is used on the result of an assignment
From: dave at codewhore dot org
Operating system: Linux 2.4
PHP version: 5CVS-2003-05-31 (dev)
PHP Bug Type: Zend Engine 2 problem
Bug description: ZE2 crashes when switch() is used on the result of an assignment
Hi:
When switching on the result of an assignment to a member variable, and
the switch statement has more than one non-default case, ZE2 crashes in
compare_function. Here's a test script:
foo = $val)
{
case 'foo':
break;
case "Remove this case and I don't crash":
break;
}
}
}
$r = new grim_reaper();
$r->slaughter('ze2');
?>
Here's some valgrind output:
==3548== Conditional jump or move depends on uninitialised value(s)
==3548==at 0x8175234: zend_case_handler
(/archive/Sources/web-server/php-5.0-cvs/Zend/zend_execute.c:3101)
==3548==by 0x816EC54: execute
(/archive/Sources/web-server/php-5.0-cvs/Zend/zend_execute.c:1247)
==3548==by 0x8173AE8: zend_do_fcall_common_helper
(/archive/Sources/web-server/php-5.0-cvs/Zend/zend_execute.c:2654)
==3548==by 0x8173F3E: zend_do_fcall_by_name_handler
(/archive/Sources/web-server/php-5.0-cvs/Zend/zend_execute.c:2725)
==3548==
==3548== Conditional jump or move depends on uninitialised value(s)
==3548==at 0x8178DF8: _get_zval_ptr
(/archive/Sources/web-server/php-5.0-cvs/Zend/zend_execute.c:73)
==3548==by 0x8175295: zend_case_handler
(/archive/Sources/web-server/php-5.0-cvs/Zend/zend_execute.c:3106)
==3548==by 0x816EC54: execute
(/archive/Sources/web-server/php-5.0-cvs/Zend/zend_execute.c:1247)
==3548==by 0x8173AE8: zend_do_fcall_common_helper
(/archive/Sources/web-server/php-5.0-cvs/Zend/zend_execute.c:2654)
==3548==
==3548== Invalid read of size 1
==3548==at 0x81557BD: compare_function
(/archive/Sources/web-server/php-5.0-cvs/Zend/zend_operators.c:1189)
==3548==by 0x8156173: is_equal_function
(/archive/Sources/web-server/php-5.0-cvs/Zend/zend_operators.c:1346)
==3548==by 0x81752AD: zend_case_handler
(/archive/Sources/web-server/php-5.0-cvs/Zend/zend_execute.c:3106)
==3548==by 0x816EC54: execute
(/archive/Sources/web-server/php-5.0-cvs/Zend/zend_execute.c:1247)
==3548==Address 0xC is not stack'd, malloc'd or free'd
Here's a gdb backtrace:
#0 0x081557bd in compare_function (result=0xbfffd47c, op1=0x0,
op2=0x821d398) at
/archive/Sources/web-server/php-5.0-cvs/Zend/zend_operators.c:1189
#1 0x08156174 in is_equal_function (result=0xbfffd47c, op1=0x0,
op2=0x821d398) at
/archive/Sources/web-server/php-5.0-cvs/Zend/zend_operators.c:1346
#2 0x081752ae in zend_case_handler (execute_data=0xbfffd4a0,
op_array=0x821e67c) at
/archive/Sources/web-server/php-5.0-cvs/Zend/zend_execute.c:3106
#3 0x0816ec55 in execute (op_array=0x821e67c) at
/archive/Sources/web-server/php-5.0-cvs/Zend/zend_execute.c:1247
#4 0x08173ae9 in zend_do_fcall_common_helper (execute_data=0xbfffd6b0,
op_array=0x82172fc)
at /archive/Sources/web-server/php-5.0-cvs/Zend/zend_execute.c:2654
#5 0x08173f3f in zend_do_fcall_by_name_handler (execute_data=0xbfffd6b0,
op_array=0x82172fc)
at /archive/Sources/web-server/php-5.0-cvs/Zend/zend_execute.c:2725
#6 0x0816ec55 in execute (op_array=0x82172fc) at
/archive/Sources/web-server/php-5.0-cvs/Zend/zend_execute.c:1247
#7 0x08159c1d in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /archive/Sources/web-server/php-5.0-cvs/Zend/zend.c:1008
#8 0x0811a3de in php_execute_script (primary_file=0xbab0) at
/archive/Sources/web-server/php-5.0-cvs/main/main.c:1678
#9 0x0817d574 in main (argc=2, argv=0xbb54) at
/archive/Sources/web-server/php-5.0-cvs/sapi/cli/php_cli.c:909
#10 0x401aabb4 in __libc_start_main () from /lib/libc.so.6
Let me know if there's anything else I can do.
Thanks,
- Dave
[EMAIL PROTECTED]
--
Edit bug report at http://bugs.php.net/?id=23925&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=23925&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=23925&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=23925&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=23925&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=23925&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=23925&r=support
Expected behavior: http://bugs.php.net/fix.php?id=23925&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=23925&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=23925&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=23925&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=23925&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=23925&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=23925&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=23925&r=gnused
#23935 [NEW]: array_key_exists no longer juggles types correctly
From: dave at codewhore dot org Operating system: Linux 2.4 PHP version: 5CVS-2003-05-31 (dev) PHP Bug Type: Arrays related Bug description: array_key_exists no longer juggles types correctly Hi: The following script produces different output with PHP 5 HEAD than it does with the PHP 4.3 stable branch: With PHP 4.3 stable, I get: bool(true) With PHP 5 HEAD, I get: bool(false) It appears that PHP 5 HEAD is missing the call to HANDLE_NUMERIC() in zend_hash_exists (Zend/zend_hash.c). The ZE2 changelog shows that it was moved: move HANDLE_NUMERIC() from the hash table implementation upstream to the places that actually need to use it. But I'm unable to figure out where the equivalent functionality was added back. Am I missing something? Thanks in advance, - Dave -- Edit bug report at http://bugs.php.net/?id=23935&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=23935&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=23935&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=23935&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=23935&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=23935&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=23935&r=support Expected behavior: http://bugs.php.net/fix.php?id=23935&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=23935&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=23935&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=23935&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=23935&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=23935&r=dst IIS Stability: http://bugs.php.net/fix.php?id=23935&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=23935&r=gnused
#24113 [NEW]: new function "str_replace_once"
From: dave at netready dot biz Operating system: Linux PHP version: 4.3.1 PHP Bug Type: Feature/Change Request Bug description: new function "str_replace_once" Hi, I have been using str_replace to search and replace over large strings. Replacing strings I know for certain only occur once. I was just thinking that maybe if there was a str_replace_once function that would stop searching after it had replaced one instance of search string this could save considerable time checking the rest of the string. To make it really useful it could have a backward/forward option so If you knew the string you are searching for occurs near the end of your string you could search backwards for it. Or would that be a separate function? I'm not sure what your guidlines are on that. This would have even more speed impact on str_ireplace because by it's nature it is slower, so maybe a str_ireplace_once would be a good idea too? -- Edit bug report at http://bugs.php.net/?id=24113&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24113&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24113&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24113&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24113&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24113&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24113&r=support Expected behavior: http://bugs.php.net/fix.php?id=24113&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24113&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24113&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24113&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24113&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24113&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24113&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24113&r=gnused
#31274 [NEW]: ISAPI for 5.03 does not load in IIS6. 5.0.2 ISAPI does load.
From: dave at pint dot com Operating system: Windows Server 2003 WE PHP version: 5.0.3 PHP Bug Type: IIS related Bug description: ISAPI for 5.03 does not load in IIS6. 5.0.2 ISAPI does load. Description: Attempted upgrade from 5.0.2 (runs stable) to 5.0.3. shutdown IIS6, copied OLD PHP directory, extracted 5.0.3 files and overwrote 5.0.2 files. Restart of IIS failed. manually removed ISAPI and app mappings from enabled sites, and restarted fine. Added new app mappings and ISAPI that pointed to 5.0.3. W3SVC would not shutdown, and only after manually killing it would restart. After several attempts of adding/removing I reverted back to the 5.0.2 release which worked on the first restart. -- Edit bug report at http://bugs.php.net/?id=31274&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31274&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31274&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31274&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31274&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31274&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31274&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31274&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31274&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31274&r=support Expected behavior: http://bugs.php.net/fix.php?id=31274&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31274&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31274&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31274&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31274&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31274&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31274&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31274&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31274&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31274&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31274&r=mysqlcfg
#24856 [NEW]: Extract taking multiple arguments
From: dave at psntn dot com Operating system: All PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: Extract taking multiple arguments Description: Would it be possible to have the extract() function to have multiple arrays passed to it in different arguments. So the code would look to see if that argument is an array, then if it is it would extract the variaables into a temp. var then apply profixes and other things then finish and return all the variables extracted from the array(s) -- Edit bug report at http://bugs.php.net/?id=24856&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24856&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24856&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24856&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24856&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24856&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24856&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24856&r=support Expected behavior: http://bugs.php.net/fix.php?id=24856&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24856&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24856&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24856&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24856&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24856&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24856&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24856&r=gnused
#24856 [Bgs]: Extract taking multiple arguments
ID: 24856 User updated by: dave at psntn dot com Reported By: dave at psntn dot com Status: Bogus Bug Type: Feature/Change Request Operating System: All PHP Version: Irrelevant New Comment: So you dont have to do: extract($thisarray); extract($thatarray); extract($theOtherArray); extract($anotherArray); Previous Comments: [2003-07-29 14:16:34] [EMAIL PROTECTED] Why? [2003-07-29 12:52:32] dave at psntn dot com Description: Would it be possible to have the extract() function to have multiple arrays passed to it in different arguments. So the code would look to see if that argument is an array, then if it is it would extract the variaables into a temp. var then apply profixes and other things then finish and return all the variables extracted from the array(s) -- Edit this bug report at http://bugs.php.net/?id=24856&edit=1
#24752 [Com]: unknown column type "uniqueidentifier", type 35
ID: 24752
Comment by: dave at daveonline dot com
Reported By: s dot sonnenberg at coolspot dot de
Status: Closed
Bug Type: MSSQL related
Operating System: Linux
PHP Version: 4.3.2
New Comment:
I am having a simular issue, however I am getting type (36) unknown and
not 35. The SQl server is Enterprise 2000. and the field is a
uniqueidentifier type. here is a line from the error:
Warning: mssql_query(): column 14 has unknown data type (36) in
/opt/mysql-standard-4.0.18-pc-linux-i686/scripts/test.php on line 34
and here is the conf file
[global]
# TDS protocol version
tds version = 8.0
; initial block size = 512
# uses some fixes required for some bugged MSSQL 7.0 server
that
# return invalid data to big endian clients
# NOTE TDS version 7.0 or 8.0 should be used instead
; swap broken dates = no
; swap broken money = no
# Database server login method, if both server and domain
# logins are enabled, domain login is tried first if a domain
# is specified, and if that fails the server login will be
used.
# OBSOLETE
; try server login = yes
; try domain login = no
# The default authentication domain, can be overridden by
# specifying a username with a domain prefix, e.g.
DOMAIN\username
# OBSOLETE use DOMAIN\username as username
; nt domain = WORKGROUP
# If the server responds with different domain try that one?
# OBSOLETE never been used
; cross domain login = no
# Whether to write a TDSDUMP file for diagnostic purposes
# (setting this to /tmp is insecure on a multi-user system)
; dump file = /tmp/freetds.log
; debug level = 10
# Command and connection timeouts
; timeout = 10
; connect timeout = 10
# If you get out of memory errors, it may mean that your
client
# is trying to allocate a huge buffer for a TEXT field.
# (Microsoft servers sometimes pretend TEXT columns are
# 4 GB wide!) If you have this problem, try setting
# 'text size' to a more reasonable limit
text size = 64512
[testserver]
host = <>
port = 1433
tds version = 8.0
Previous Comments:
[2004-02-25 03:04:03] s dot sonnenberg at coolspot dot de
I use exactly the combination : PHP 4.3.4 + FreeTDS 0.61.2.
And we have no such problems.
Could you please send your configure strings ?
[2004-02-20 11:54:47] rgesse at ndigital dot com
I ran into the same problem wih the latest version of PHP and Freetds
(as of Feb. 18, 2004). I found that the only way to SELECT from a
uniqueidentifier field is the following:
SELECT LEFT(CAST(uniqueidentifierfield as char(64)), 36) AS thisfield
FROM table
[2003-07-23 11:56:21] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-07-22 08:29:36] s dot sonnenberg at coolspot dot de
Description:
If you use the combination FreeTDS 0.61 + PHP 4.3.2 to access
data on a MS SQL Server 2000, columns of type "uniqueidentifier" (type
35) or causing php to barf, and you are not able to handle them.
I got it to work after a applying a patch, that I figure out :
for ext/mssql/php_mssql.c :
--- php-4.3.2/ext/mssql/php_mssql.c 2003-05-21 02:06:41.0
+0200
+++ php-4.3.2-LOCAL/ext/mssql/php_mssql.c 2003-07-22
13:34:35.0
+0200
@@ -800,6 +800,15 @@
Z_DVAL_P(result) = (double) floatcol8(offset);
Z_TYPE_P(result) = IS_DOUBLE;
break;
+ case SQLUNIQUE:
+ {
+ int length = 16;
+ char *data = charcol(offset);
+ Z_STRVAL_P(result) =
estrndup(data,length);
+ Z_STRLEN_P(result) = length;
+ Z_TYPE_P(result) = IS_STRING;
+ }
+ break;
case SQLVARBINARY:
case SQLBINARY:
case SQLI
Bug #53585 [Com]: PNG support broken, Abort trap: 6 (core dumped)
Edit report at https://bugs.php.net/bug.php?id=53585&edit=1 ID: 53585 Comment by: dave at jetcafe dot org Reported by:serge dot sitnikov at gmail dot com Summary:PNG support broken, Abort trap: 6 (core dumped) Status: Not a bug Type: Bug Package:GD related Operating System: FreeBSD 8.1-RELEASE PHP Version:5.3.4 Block user comment: N Private report: N New Comment: Confirmed and duplicated on FreeBSD 7.3-RELEASE. Moving a crashing extension to the top just moves the bug down. I am unable to find any determinism (which doesn't mean none exists) in this. I appreciate that both the FreeBSD camps and PHP camps are pointing at each other. It would be greatly appreciated by those of us having a problem if someone from both camps could take a cooperative look. Thank you. :) Previous Comments: [2012-02-13 13:55:02] erik at erik dot eu By changing the order in extensions.ini the problem doesn't go away. It's moved to the latter module. with sequence; --- snip of extensions.ini --- extension=pdf.so extension=gd.so --- pdf_load_image($pdfObject,"png", 'someimage.png'); will work But png functions from GD won't! with sequence; --- snip of extensions.ini --- extension=gd.so extension=pdf.so --- GD works but pdf_load_image will segfault. doing portupgrade will alter the sequence in extensions.ini so GD works and it looks like problems are solved. But loading png in pdf will fail. Enviroment; Freebsd 8.2-RELEASE php5.3.10 just did portmaster -r png (13-feb-2012) [2011-11-17 00:17:04] andy at fud dot org dot nz I can reproduce this on FreeBSD 8.2-RELEASE (amd64) the test script is test.png can be found at https://gg.net.nz/X/test.png If I have the pdf extension loaded before gd (in extensions.ini) then I get an abort --- snip of extensions.ini --- extension=pdf.so extension=gd.so --- % php test.php zsh: abort (core dumped) php t.php If I load gd first then the issue goes away --- snip of extensions.ini --- extension=gd.so extension=pdf.so --- % php test.php ok The software versions are: php5-5.3.8 php5-gd-5.3.8 pdflib-7.0.4 pecl-pdflib-2.1.8 png-1.4.8 [2010-12-21 11:03:06] paj...@php.net Then it is definitively not a PHP problem. The tests suite work just fine, and all PNGs I use for testing as well (from the PNG tests suite and some other). Please report the issue to FreeBSD or update it as suggested in the other comment. [2010-12-21 10:48:03] serge dot sitnikov at gmail dot com @paj...@php.net You may test on that image, for example: http://upload.wikimedia.org/wikipedia/commons/7/7a/Basketball.png [2010-12-21 10:40:54] serge dot sitnikov at gmail dot com @paj...@php.net Image does not matter. Any PNG image I have tested lead to the same result -- core dumped. Already tested that on two machines. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=53585 -- Edit this bug report at https://bugs.php.net/bug.php?id=53585&edit=1
Req #46506 [Com]: readonly attribute for (public) class variables
Edit report at https://bugs.php.net/bug.php?id=46506&edit=1
ID: 46506
Comment by: dave at shax dot com
Reported by:glideraerobatics at hotmail dot com
Summary:readonly attribute for (public) class variables
Status: Open
Type: Feature/Change Request
Package:*General Issues
PHP Version:5.4
Block user comment: N
Private report: N
New Comment:
'readonly' property as described here would be extremely useful to me
in daily development.
Doesn't need to be fancy. The most obvious functionality, as described
by others above, is exactly what I want. At the moment, I duplicate
this functionality in 90% my classes using __get().
There's presumably a bit of a performance knock in doing it with
__get() (never benchmarked it, but it seems obvious) - not routing
the read requests for each property through __get() or a separate
getter function saves a function call and would be faster.
Because I currently use __get() on nearly every major object in my
application, I could easily save several hundred function calls per
request, which is probably creating a measurable difference in page
generation.
It may seem CRAZY to accept performance slowdown for something this
trivial, but for me having each object defined as an individual solid
API in its own right makes my code much more stable, and in a large
application prevents unwanted/accidental interference from outside
modules. It's mainly about being SUPER sure I've internally validated
all data that's entering each object - hardening it!
At the moment my options are to make it writable by anyone, or accept
a performance hit - this is why I'm very keen for this to be added to
the language!
For the implementation of this, I'd want it to be like 'protected',
not 'private' wherein other classes that inherit the property can
also write to it.
Previous Comments:
[2013-03-31 09:09:16] glideraerobatics at hotmail dot com
@stian dot pedersen at gmail dot com
A "property" keyword isn't good enough because you still need the scope
keywords
public and protected at least. That's why I used the C# convention in the 1st
post.
[2013-03-30 18:40:43] stian dot pedersen at gmail dot com
This feature is seconded. Basically it would be useful to have a modifier which
allows internal modification but disallows public reassignment. By an example,
letting "property" be the new key word,
class Order
{
property $customer;
}
class Order
{
private $customer;
public getCustomer(){return $this->customer;}
}
$order->customer and $order->getCustomer() could have the same semantics in
that
a "copy of the pointer" in C terms is returned and you cannot call $order-
>customer = null any more than you could call $order->getCustomer() = null.
However, $customer itself should be modifyable, for instance, $order->customer-
>id = 1000, if id is declared as public. This would be more in tune of mat dot
barrie at gmail dot com and very useful in OOP.
Inside the class, I would prefer to be able to reassign customer at will (even
after constructor).
Syntactically it would be nice to chose a syntax that would allow support for
setters also, but for now, I would be happy with this. It sorta does the same
thing as the __get() trick but does not mess up IDE support and will probably
execute faster.
[2012-11-27 15:55:04] info at strictcoding dot co dot uk
+1 for this awesome feature. Any reviews from the PHP team?
[2012-09-18 21:53:20] mat dot barrie at gmail dot com
As a point of interest, the C# readonly keyword mentioned actually does not
protect exposed classes from being modified, it prevents assignment. So from
your example if you duplicate the C# behaviour, this is what it actually would
work like this, which I don't think is what you're asking for:
--
$count = count($parent->children); // You can do this
$name = $parent->children[0]; // You can even do this
$parent->children[0] = "BILLY"; // You can still do this
$parent->children[] = "BOB"; // And you can still even do this
$parent->children = NULL; // But not this
unset($parent->children); // Or this
--
A readonly attribute probably isn't what's needed here (after all, you're not
actually asking for a property that can be made readonly) but instead if the
protection level could be defined on the getter and setter independently, so
that set could be defined as private and get as public. _
#48860 [NEW]: Data in SplQueue objects is not persistent
From: dave at dtracorp dot com
Operating system: windows xp
PHP version: 5.3.0
PHP Bug Type: SPL related
Bug description: Data in SplQueue objects is not persistent
Description:
I'm trying to store an SplQueue object in the session, on page reload the
SplQueue object is still there, but it has no data. This happens on Windows
XP (Apache 2.0.58), but also on Fedora 8 (apache 2.2), and a Debian build
running apache 2.2.
Reproduce code:
---
enqueue('something');
$q->enqueue('over there');
session_start();
$_SESSION['q'] = $q;
?>
on the second page
';
print_r($q);
Expected result:
SplQueue Object
(
[flags:SplDoublyLinkedList:private] => 4
[dllist:SplDoublyLinkedList:private] => Array
(
[0] => something
[1] => over there
)
)
Actual result:
--
SplQueue Object
(
[flags:SplDoublyLinkedList:private] => 4
[dllist:SplDoublyLinkedList:private] => Array
(
)
)
--
Edit bug report at http://bugs.php.net/?id=48860&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48860&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48860&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48860&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48860&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48860&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48860&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48860&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48860&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48860&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48860&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48860&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48860&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48860&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48860&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48860&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48860&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48860&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48860&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48860&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48860&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48860&r=mysqlcfg
#41966 [Com]: cannot set include_path in php.ini
ID: 41966 Comment by: dave at dtracorp dot com Reported By: badaboom003-asdf at yahoo dot com Status: No Feedback Bug Type: PHP options/info functions Operating System: Ubuntu 7.04 Feisty Fawn AMD64 PHP Version: 5.2.3 New Comment: this just happened to me as well, on a debian machine just randomly, i was updating some code, and then for some reason it just stopped working using php 5.3.0, the include_path is set, /several/paths/to/include in the php.ini it is the correct php.ini, as it says in phpinfo(), when i remove the ini file, the include path stays the same, /path/to/php/install/lib/php when i put the ini file back, it still says that php built as a cgi Previous Comments: [2009-03-18 19:07:37] jeffreyd dot davis at gmail dot com This is still a problem with PHP 5.2.5. I am running on a Redhat system. I can confirm that I am loading the correct php.ini file but my changes have no effect. My changes to the path show up in phpinfo(), But when I run get_include_path() it always shows the default path instead of my changes. Also, running set_include_path() no longer has any effect, either. This latter problem is only true as of PHP 5.2.5 [2007-07-19 01:00:04] 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". [2007-07-11 18:39:53] sni...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi And check phpinfo() output for what php.ini files was loaded and actually in use. [2007-07-11 17:28:07] badaboom003-asdf at yahoo dot com Description: Using: Apache/2.2.3 (Ubuntu) PHP/5.2.1 can't change the include_path in php.ini. it always defaults to: ".:/usr/share/php:/usr/share/pear". i know i'm using the correct php.ini file because it shows the correct Configuration File Path in phpinfo(). i can successfully set other variables in php.ini such as memory_limit or whatever, restart apache, and everything works fine. however, when i try to change the include_path, nothing happens. Reproduce code: --- ; UNIX: "/path1:/path2" include_path = ".:/usr/share/php:/usr/share/php/PEAR:/var/somesite/app/classes" ; ; Windows: "\path1;\path2" ;include_path = ".;c:\php\includes" Expected result: when i run phpinfo() i should see: include_path .:/usr/share/php:/usr/share/pear:/var/somesite/app/classes Actual result: -- what i actually see is: include_path .:/usr/share/php:/usr/share/pear -- Edit this bug report at http://bugs.php.net/?id=41966&edit=1
#41966 [Com]: cannot set include_path in php.ini
ID: 41966 Comment by: dave at dtracorp dot com Reported By: badaboom003-asdf at yahoo dot com Status: No Feedback Bug Type: PHP options/info functions Operating System: Ubuntu 7.04 Feisty Fawn AMD64 PHP Version: 5.2.3 New Comment: try running php -i | grep include_path from the command line, perhaps there is a syntax error in your php.ini Previous Comments: [2009-07-10 10:20:41] dave at dtracorp dot com this just happened to me as well, on a debian machine just randomly, i was updating some code, and then for some reason it just stopped working using php 5.3.0, the include_path is set, /several/paths/to/include in the php.ini it is the correct php.ini, as it says in phpinfo(), when i remove the ini file, the include path stays the same, /path/to/php/install/lib/php when i put the ini file back, it still says that php built as a cgi [2009-03-18 19:07:37] jeffreyd dot davis at gmail dot com This is still a problem with PHP 5.2.5. I am running on a Redhat system. I can confirm that I am loading the correct php.ini file but my changes have no effect. My changes to the path show up in phpinfo(), But when I run get_include_path() it always shows the default path instead of my changes. Also, running set_include_path() no longer has any effect, either. This latter problem is only true as of PHP 5.2.5 [2007-07-19 01:00:04] 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". [2007-07-11 18:39:53] sni...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi And check phpinfo() output for what php.ini files was loaded and actually in use. [2007-07-11 17:28:07] badaboom003-asdf at yahoo dot com Description: Using: Apache/2.2.3 (Ubuntu) PHP/5.2.1 can't change the include_path in php.ini. it always defaults to: ".:/usr/share/php:/usr/share/pear". i know i'm using the correct php.ini file because it shows the correct Configuration File Path in phpinfo(). i can successfully set other variables in php.ini such as memory_limit or whatever, restart apache, and everything works fine. however, when i try to change the include_path, nothing happens. Reproduce code: --- ; UNIX: "/path1:/path2" include_path = ".:/usr/share/php:/usr/share/php/PEAR:/var/somesite/app/classes" ; ; Windows: "\path1;\path2" ;include_path = ".;c:\php\includes" Expected result: when i run phpinfo() i should see: include_path .:/usr/share/php:/usr/share/pear:/var/somesite/app/classes Actual result: -- what i actually see is: include_path .:/usr/share/php:/usr/share/pear -- Edit this bug report at http://bugs.php.net/?id=41966&edit=1
#47258 [NEW]: PHP 5.2.8 / MySQL 5.1.30 Causes Apache to Crash
From: dave at salesanswer dot com Operating system: Windows PHP version: 5.2.8 PHP Bug Type: Reproducible crash Bug description: PHP 5.2.8 / MySQL 5.1.30 Causes Apache to Crash Description: I just downloaded and installed on Windows XP: PHP 5.2.8 MySQL 5.1.30 Community version Apache 2.2.11 I then imported a basic working Drupal site. It behaves oddly, only the main page displays, www.mydomain.com/node/99 does not work. phpMyAdmin was complaining that the MySQL PHP Library version was different than the MySQL version. So I copied the libarary from the MySQL bin directory and rebooted. When you go to localhost in the browser, Apache crashes. Switching the library back to the one shipped with PHP stops the crashing but again the main page only displays. If I uninstall everything and install XAMPP, and import the Drupal site, everything works fine. However, I would rather not use XAMPP as the MySQL tools are not as fully featured, compared to the MySQL Comuunity Version install available from Sun. Reproduce code: --- See Above. Expected result: See Above. Actual result: -- See Above. -- Edit bug report at http://bugs.php.net/?id=47258&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47258&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47258&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47258&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47258&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47258&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47258&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47258&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47258&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47258&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47258&r=support Expected behavior: http://bugs.php.net/fix.php?id=47258&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47258&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47258&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47258&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47258&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47258&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47258&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47258&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47258&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47258&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47258&r=mysqlcfg
#39904 [Com]: string -> boolean conversion of "\0" could give FALSE
ID: 39904
Comment by: dave at ifox dot com
Reported By: zizka at seznam dot cz
Status: Open
Bug Type:Feature/Change Request
PHP Version: 5.2.0
New Comment:
This is by far the worst thing that has found itself into PHP.
Previous Comments:
[2006-12-20 14:46:44] zizka at seznam dot cz
Description:
It might be useful that (boolean)"\0" would give FALSE.
E.g. MySQL's BIT(1) column type can be used to store boolean values,
but now PHP converts whatever value to TRUE.
Reproduce code:
---
header('Content-Type: text/plain');
echo "\nfalse: ".ord(false);
echo "\ntrue: ".ord(true);
echo "\n\\0: ".(boolean)("\0");
echo "\n\\1: ".(boolean)("\1");
// ord() is here just for thoughts context...
Expected result:
false: 0
true: 49
\0: 0
\1: 1
Actual result:
--
false: 0
true: 49
\0: 1 <- HERE
\1: 1
--
Edit this bug report at http://bugs.php.net/?id=39904&edit=1
#48012 [NEW]: String "0" conversion to boolean FALSE is not logical.
From: dave at ifox dot com
Operating system: All
PHP version: 5.3.0RC1
PHP Bug Type: Feature/Change Request
Bug description: String "0" conversion to boolean FALSE is not logical.
Description:
PHP Developers,
I typed a very logical explanation of why more careful thought should have
been put into the addition of this conversion:
"0" => FALSE
but the submission failed and so I will try to reproduce it.
When I learned about the exception of the string "0" converting to a
boolean false, I had a sick feeling in my stomach. An entire team of
language developers fell down the slippery slope caused by a handful of
programmers in 2003 and 2004 that wanted to shorten their code, and thought
that "0" -> TRUE was a bug.
Every other language in existence converts a non-empty string to a boolean
TRUE, because they prevail in this logic: the only meaning that SHOULD be
derived from an alphanumeric string is its alphanumeric content, unless
first cast to a numeric (or other) type. For a language that tries to
bring in the best of other languages, PHP should at least mimic the logical
behavior of those languages.
I have edited dozens of web sites to fix well-structured code by skilled
programmers that didn't expect this behavior, particularly when checking
for the existence of strings from databases or user input (form POSTs). As
an example:
if ($_POST["uid"] && ...) { ... }
now must be changed to:
if (strlen($_POST["uid"]) && ...) { ... }
and sometimes there are dozens of these in series. This begs programmers
to be sloppy and just let "0" fail as an unusual case even when valid as
input. And even skilled programmers can't be expected to read and catch
this tiny exception in your documentation.
There are other ramifications from not respecting the alphanumeric string
for the purpose it was intended, to hold alphanumeric values. I will not
expound here. The fact that FORM POSTs yield strings is not something to
streamline in to the assumption that a user "meant" to enter an integer.
Only a beginning programmer wanting a shortcut hack would expect or want
this behavior.
And what of " 0", "0 ", "00", "false", and "0.0"? They are respected!
Originally I thought the "0" conversion was an attempt to make
bool(string(FALSE)) == FALSE, but it already does since string(FALSE) == ""
(although in other languages, it yields TRUE, because it is appropriate to
conclude that the string representation of any boolean value has length and
is therefore TRUE).
JavaScript, as a common example, understands what an alphanumeric string
is for:
if ('0') document.write('YES');
This yields "YES", of course. Unfortunately there are now people out
there posting that JavaScript is broken. But they are beginners, of
course. A language should never make assumptions about a programmer's
users' intent when providing input. If a user intends "0" as a string, why
assume that is a numerical value? Don't you need to now assume all sorts
of zero-value strings?
I have developed two loosely-typed languages, and I made the choice to
treat non-empty strings as TRUE. I find PHP for the web very usable, but I
was completely surprised by this choice, and I'm sorry to say that it has
resulted in high-quality code yielding unexpected subtle failures for its
users.
I modified PHP (14 or so changes in the Zend engine) to remove the feature
and I made a patch. The ill stomach went away, and PHP now respects
alphanumeric strings, but now I am uniquely conscious in a world of
assumptions yielding unexpected results. I guess that's the beauty and
curse of open source.
What were the thought processes in creating this "feature"? Please
consider its removal!
Dave May
Reproduce code:
---
$str = "0";
if ($str) echo "TRUE"; else echo "FALSE";
---
>From manual page: language.types.boolean
---
Expected result:
TRUE
Actual result:
--
FALSE
--
Edit bug report at http://bugs.php.net/?id=48012&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48012&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48012&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48012&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48012&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48012&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48012&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48012&r=needtrace
Need Reproduce
#39904 [Com]: string -> boolean conversion of "\0" could give FALSE
ID: 39904
Comment by: dave at ifox dot com
Reported By: zizka at seznam dot cz
Status: Open
Bug Type:Feature/Change Request
PHP Version: 5.2.0
New Comment:
To correct, "\0" -> FALSE has not found itself into PHP, but "0" has,
and that feature should be reversed. It's not logical to assume the
numerical value of alphanumeric strings in place of the programmer doing
so with a numerical cast.
A bug report was even submitted that a string "false" should evaluate
to FALSE when converted to boolean. That won't happen, because PHP
developers already know they made a mistake with the "0" hack.
Hopefully in a major version release it will be reversed and all
non-empty strings will evaluate to TRUE.
Just like every other loosely-typed language on the planet.
Previous Comments:
----
[2009-04-17 23:56:47] dave at ifox dot com
This is by far the worst thing that has found itself into PHP.
[2006-12-20 14:46:44] zizka at seznam dot cz
Description:
It might be useful that (boolean)"\0" would give FALSE.
E.g. MySQL's BIT(1) column type can be used to store boolean values,
but now PHP converts whatever value to TRUE.
Reproduce code:
---
header('Content-Type: text/plain');
echo "\nfalse: ".ord(false);
echo "\ntrue: ".ord(true);
echo "\n\\0: ".(boolean)("\0");
echo "\n\\1: ".(boolean)("\1");
// ord() is here just for thoughts context...
Expected result:
false: 0
true: 49
\0: 0
\1: 1
Actual result:
--
false: 0
true: 49
\0: 1 <- HERE
\1: 1
--
Edit this bug report at http://bugs.php.net/?id=39904&edit=1
#48012 [WFx]: String "0" conversion to boolean FALSE is not logical.
ID: 48012
User updated by: dave at ifox dot com
Reported By: dave at ifox dot com
Status: Wont fix
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.3.0RC1
New Comment:
Thanks for the response, but I see you misunderstood my post. I was
talking about string-to-boolean conversion, not string-to-integer
conversion.
Implicit conversion of string to integer is correct in PHP:
'0' == 0 yields TRUE, of course
'123' == 123 yields TRUE, of course
' 45 ' == 45 yields TRUE, of course
'' == 0 yields TRUE, of course
I'm talking only about the special case that doesn't hold up well
logically. In conversion to boolean (explicit or implicit):
'Hello' yields TRUE, string is non-empty
' ' yields TRUE, string is non-empty
'123' yields TRUE, string is non-empty
'00' yields TRUE, string is non-empty (regardless of zero
value)
' 0' yields TRUE, string is non-empty (regardless of zero value)
'0 ' yields TRUE, string is non-empty (regardless of zero value)
'0.0' yields TRUE, string is non-empty (regardless of zero value)
'0x0' yields TRUE, string is non-empty (regardless of zero value)
''yields FALSE, string is empty
'0' yields FALSE, even though string is non-empty, simply because of
a single ASCII '0' ???
But wait, '0' is an alphanumeric string! PHP is now the only language
in the world, web or otherwise, that would make an assumption about a
string's NUMERIC value when converting to a BOOLEAN. It may have been
more appropriate to follow other languages which only analyze the
presence of CONTENT in the string.
Am I at least making sense?
Obviously you won't take the step to assuming '0.0' is false, or any of
the silly ideas people have submitted as reports ('false'), but why take
the initial step?
By the same logic that you would argue '0.0' is an alphanumeric string
and ' 0 ' is an alphanumeric string, and should not be interpreted as a
boolean false, you should argue that '0' gets the same protection from
coercion to a numeric value just for the boolean evaluation (and test).
Of course, you could have deviated more drastically, and performed a
numerical evaluation of every string, and see if it contains a zero
number, and that would be incredibly inefficent, but it would follow
your logic.
If you do see my point, and have compared to other languages, you may
see what I'm talking about.
A change of this behavior would yield fewer errors by programmers that
liked the C-, Java- and JavaScript-esque beauty of PHP but didn't catch
it in the documentation (most programmers). However, I realize why you
might not change the behavior -- existing code might make assumptions
about user input that is intended as numerical and where tests against
that numerical value are made. But realize those programs are already
having to convert to integer anyway, because " 0" would be interpreted
as non-zero. You see?
I just wanted to comment, and hope that you recognize that this is
unusual, and it leads to broken programs -- I know, I've fixed them!
Thanks of course!
Previous Comments:
[2009-04-18 19:28:05] ras...@php.net
PHP is first and foremost a Web language, not a general-purpose
scripting language. Since the Web is not typed and everything is a
string, I had to do things slightly differently early on to make PHP do
what people expected. Specifically, "123"==123 needs to be true in
order to not have to type cast every single numeric user input. Given
that, then it also follows that '0'==0 and if you continue with that and
consider that 0==false then it makes sense that '0'==false.
However, '0'===false is, of course, false. This is why we have the
strict type-comparison operators in PHP.
Basically if we change '0' to be true, then we also have to trickle
that change up resulting in '123'!=123 which would break every app out
there. So, while I understand your point, it simply isn't going to
happen.
[2009-04-18 19:05:48] dave at ifox dot com
Description:
PHP Developers,
I typed a very logical explanation of why more careful thought should
have been put into the addition of this conversion:
"0" => FALSE
but the submission failed and so I will try to reproduce it.
When I learned about the exception of the string "0" converting to a
boolean false, I had a sick feeling in my stomach. An entire team of
language dev
#48012 [WFx]: String "0" conversion to boolean FALSE is not logical.
ID: 48012
User updated by: dave at ifox dot com
Reported By: dave at ifox dot com
Status: Wont fix
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.3.0RC1
New Comment:
That's not what I was saying was being misinterpreted.
You took a failed logical path. To quote you:
---
Specifically, "123"==123 needs to be true in
order to not have to type cast every single numeric user input. Given
that, then it also follows that '0'==0 and if you continue with that and
consider that 0==false then it makes sense that '0'==false.
---
And yet '0 '==true? (note the space here and after)
By your own logic, '0 '==0 and therefore it makes sense that '0
'==false. But '0 '==true in PHP. So you DO have to "type cast every
single numeric user input" (your words), whereas your point is that
because of this special '0' check, you don't. False conclusion. The
purpose of the check for a single alphanumeric zero in a string gained
you nothing, you see. And trimming the string doesn't correct '00', or
'-0', to further illustrate.
Of course it shouldn't. My point is that you *should* have to cast
strings to integer if doing a simple non-zero test.
Of course the additional problem is now you have to call strlen() to
check for the presence of content, to sidestep this check.
I will note that by your logic, since 'joe'==0, it should follow that
'joe'==false. Hence the contradictions that arise when you try to prove
your point.
It's not a bug, and it's documented. No problem with that. Apparently
it's been this way from as early as 2002. If I don't like that PHP is
illogical, I can write my own language. Oh wait, I did. I'm just trying
to help you folks out, and make it so these programs that end up on my
desk don't have such strange behavior.
Cheers!
Previous Comments:
[2009-04-18 20:38:37] ras...@php.net
No, I didn't misunderstand.
if($val) is equivalent to if($val==true)
[2009-04-18 20:10:32] dave at ifox dot com
Thanks for the response, but I see you misunderstood my post. I was
talking about string-to-boolean conversion, not string-to-integer
conversion.
Implicit conversion of string to integer is correct in PHP:
'0' == 0 yields TRUE, of course
'123' == 123 yields TRUE, of course
' 45 ' == 45 yields TRUE, of course
'' == 0 yields TRUE, of course
I'm talking only about the special case that doesn't hold up well
logically. In conversion to boolean (explicit or implicit):
'Hello' yields TRUE, string is non-empty
' ' yields TRUE, string is non-empty
'123' yields TRUE, string is non-empty
'00' yields TRUE, string is non-empty (regardless of zero
value)
' 0' yields TRUE, string is non-empty (regardless of zero value)
'0 ' yields TRUE, string is non-empty (regardless of zero value)
'0.0' yields TRUE, string is non-empty (regardless of zero value)
'0x0' yields TRUE, string is non-empty (regardless of zero value)
''yields FALSE, string is empty
'0' yields FALSE, even though string is non-empty, simply because of
a single ASCII '0' ???
But wait, '0' is an alphanumeric string! PHP is now the only language
in the world, web or otherwise, that would make an assumption about a
string's NUMERIC value when converting to a BOOLEAN. It may have been
more appropriate to follow other languages which only analyze the
presence of CONTENT in the string.
Am I at least making sense?
Obviously you won't take the step to assuming '0.0' is false, or any of
the silly ideas people have submitted as reports ('false'), but why take
the initial step?
By the same logic that you would argue '0.0' is an alphanumeric string
and ' 0 ' is an alphanumeric string, and should not be interpreted as a
boolean false, you should argue that '0' gets the same protection from
coercion to a numeric value just for the boolean evaluation (and test).
Of course, you could have deviated more drastically, and performed a
numerical evaluation of every string, and see if it contains a zero
number, and that would be incredibly inefficent, but it would follow
your logic.
If you do see my point, and have compared to other languages, you may
see what I'm talking about.
A change of this behavior would yield fewer errors by programmers that
liked the C-, Java- and JavaScript-esque beauty of PHP but didn&
Bug #51870 [Com]: PDO::fetchAll after a PDO::execute with bindings lead to a segv.
Edit report at http://bugs.php.net/bug.php?id=51870&edit=1
ID: 51870
Comment by: dave at hobodave dot com
Reported by: d...@php.net
Summary: PDO::fetchAll after a PDO::execute with bindings lead
to a segv.
Status: Closed
Type: Bug
Package: PDO related
Operating System: Mac OS X
PHP Version: 6SVN-2010-05-20 (SVN)
Assigned To: mysql
New Comment:
This still exists in the latest snapshot php5.3-201005211630.tar.gz
Test
prepare('SHOW FULL TABLES');
$stm->execute();
$stm->fetchAll();
Previous Comments:
[2010-05-21 13:09:59] and...@php.net
Fixed in SVN, thank you for your report!
[2010-05-21 13:09:30] and...@php.net
Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revision&revision=299574
Log: Fix for Bug #51870
PDO::fetchAll after a PDO::execute with bindings lead to a segv.
It is only in unreleased code and thus doesn't deserve a NEWS entry
[2010-05-21 09:21:48] d...@php.net
Hunting down the bug it seems that
mysqlnd.collect_memory_statistics = On
causes troubles.
[2010-05-20 13:46:45] d...@php.net
Sorry I forgot to add my configure:
'./configure' \
'--with-mysql=mysqlnd' \
'--with-pdo-mysql=mysqlnd' \
[2010-05-20 13:43:54] m...@php.net
erm, this should have been http://snaps.php.net/php-trunk-latest.tar.gz
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=51870
--
Edit this bug report at http://bugs.php.net/bug.php?id=51870&edit=1
Bug #51870 [Com]: PDO::fetchAll after a PDO::execute with bindings lead to a segv.
Edit report at http://bugs.php.net/bug.php?id=51870&edit=1
ID: 51870
Comment by: dave at hobodave dot com
Reported by: d...@php.net
Summary: PDO::fetchAll after a PDO::execute with bindings lead
to a segv.
Status: Closed
Type: Bug
Package: PDO related
Operating System: Mac OS X
PHP Version: 6SVN-2010-05-20 (SVN)
Assigned To: mysql
New Comment:
#0 0x7fff82410886 in __kill ()
#1 0x7fff824b0eae in abort ()
#2 0x7fff823c8a75 in free ()
#3 0x0001020eefc5 in pdo_mysql_stmt_fetch ()
#4 0x00010008bffe in do_fetch_common ()
#5 0x00010008c107 in do_fetch ()
#6 0x00010008e3bf in zim_PDOStatement_fetchAll ()
#7 0x00010020359a in zend_do_fcall_common_helper_SPEC ()
#8 0x0001001ff93b in execute ()
#9 0x0001001db29b in zend_execute_scripts ()
#10 0x000100183d62 in php_execute_script ()
#11 0x00010026c985 in main ()
Previous Comments:
[2010-05-21 19:47:29] dave at hobodave dot com
This still exists in the latest snapshot php5.3-201005211630.tar.gz
Test
prepare('SHOW FULL TABLES');
$stm->execute();
$stm->fetchAll();
[2010-05-21 13:09:59] and...@php.net
Fixed in SVN, thank you for your report!
[2010-05-21 13:09:30] and...@php.net
Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revision&revision=299574
Log: Fix for Bug #51870
PDO::fetchAll after a PDO::execute with bindings lead to a segv.
It is only in unreleased code and thus doesn't deserve a NEWS entry
[2010-05-21 09:21:48] d...@php.net
Hunting down the bug it seems that
mysqlnd.collect_memory_statistics = On
causes troubles.
[2010-05-20 13:46:45] d...@php.net
Sorry I forgot to add my configure:
'./configure' \
'--with-mysql=mysqlnd' \
'--with-pdo-mysql=mysqlnd' \
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=51870
--
Edit this bug report at http://bugs.php.net/bug.php?id=51870&edit=1
Bug #51870 [Com]: PDO::fetchAll after a PDO::execute with bindings lead to a segv.
Edit report at http://bugs.php.net/bug.php?id=51870&edit=1
ID: 51870
Comment by: dave at hobodave dot com
Reported by: d...@php.net
Summary: PDO::fetchAll after a PDO::execute with bindings lead
to a segv.
Status: Assigned
Type: Bug
Package: PDO related
Operating System: Mac OS X
PHP Version: 6SVN-2010-05-20 (SVN)
Assigned To: mysql
New Comment:
Please disregard my previous comments. My environment was screwed, and
an old
pdo_mysql version was being loaded dynamically.
Previous Comments:
[2010-05-21 20:12:31] johan...@php.net
re-open after comment from dave.
[2010-05-21 19:55:25] dave at hobodave dot com
#0 0x7fff82410886 in __kill ()
#1 0x7fff824b0eae in abort ()
#2 0x7fff823c8a75 in free ()
#3 0x0001020eefc5 in pdo_mysql_stmt_fetch ()
#4 0x00010008bffe in do_fetch_common ()
#5 0x00010008c107 in do_fetch ()
#6 0x00010008e3bf in zim_PDOStatement_fetchAll ()
#7 0x00010020359a in zend_do_fcall_common_helper_SPEC ()
#8 0x0001001ff93b in execute ()
#9 0x0001001db29b in zend_execute_scripts ()
#10 0x000100183d62 in php_execute_script ()
#11 0x00010026c985 in main ()
[2010-05-21 19:47:29] dave at hobodave dot com
This still exists in the latest snapshot php5.3-201005211630.tar.gz
Test
prepare('SHOW FULL TABLES');
$stm->execute();
$stm->fetchAll();
[2010-05-21 13:09:59] and...@php.net
Fixed in SVN, thank you for your report!
[2010-05-21 13:09:30] and...@php.net
Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revision&revision=299574
Log: Fix for Bug #51870
PDO::fetchAll after a PDO::execute with bindings lead to a segv.
It is only in unreleased code and thus doesn't deserve a NEWS entry
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=51870
--
Edit this bug report at http://bugs.php.net/bug.php?id=51870&edit=1
Bug #32330 [Com]: session_destroy, "Failed to initialize storage module", custom session handler
Edit report at http://bugs.php.net/bug.php?id=32330&edit=1 ID: 32330 Comment by: dave at redterror dot net Reported by: mfisc...@php.net Summary: session_destroy, "Failed to initialize storage module", custom session handler Status: Closed Type: Bug Package: Session related Operating System: * PHP Version: 6CVS, 5CVS, 5.2.5, 4CVS (2005-03-17) New Comment: Any chance the fix could be backported to 5.2, or I can get a reference to the fix that was applied? I didn't see this bug number in the changelog. I am still seeing the problem on 5.2.12, which was released almost 2 years after the fix was reported to have gone in. Previous Comments: [2008-07-02 10:11:21] j...@php.net Note: This fix will be in PHP 5.3 and upwards. [2008-03-07 23:21:44] gwy...@php.net 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. [2008-02-23 06:43:59] fxmulder at gmail dot com The problem is both mod_data getting set to NULL and zval_ptr_dtor(&mdata->names[i]); for each of the functions in ext/session/mod_user.c:PS_CLOSE_FUNC. If the deconstructor calls are removed as well as the NULL replacements and efree() call on mdata then it works, except then the containing classes are never deconstructed. This could possibly be moved to a location when the script is exiting, and/or another call to session_set_save_handler is made. [2008-01-22 05:43:48] gwy...@php.net This bug still exists in PHP 5.2.5 release and current (as of this comment) PHP 6CVS. Using a fresh call to session_set_save_handler() does work, but as previously noted by others, this isn't a desirable behavior. [2007-08-23 05:25:49] jkloske at itee dot uq dot edu dot au I'm confirming that I'm also affected by this on all OSs and all versions of PHP I've tried it with (4/5, win/linux) I'm calling session_write_close() not session_destroy() and it's still causing the same error. Re-calling session_set_save_handler between previous close and subsequent open does nothing; the error still occurs. This means that phpMyAdmin (which uses multiple sessions for various authentication handlers at least) is not compatible with user session handlers, due to this bug :) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=32330 -- Edit this bug report at http://bugs.php.net/bug.php?id=32330&edit=1
Bug #52257 [Com]: module php5-librdf causes libxslt's security module to fail
Edit report at http://bugs.php.net/bug.php?id=52257&edit=1
ID: 52257
Comment by: dave at dajobe dot org
Reported by:matth at mlalonde dot net
Summary:module php5-librdf causes libxslt's security module
to fail
Status: Open
Type: Bug
Package:XSLT related
Operating System: Ubuntu LTS
PHP Version:5.3.2
Block user comment: N
New Comment:
(Found the add comment button!)
Just to explain a bit more why raptor does this.
It's using libxslt as part of the GRDDL rdf parser to execute XSLT
scripts off the web, never from local files. So it makes sense to
refuse any local file read/write as the default security policy.
This does however conflict with general user-use of libxslt on local
files in another module, such as PHP's xslt module.
So in one memory namespace, you need to be both restrictive and
permissive, yet the *default* security policy can only be set
libxslt-wide:
http://www.xmlsoft.org/XSLT/html/libxslt-security.html#xsltSetDefaultSecurityPrefs
The context-specific policy can be different:
http://www.xmlsoft.org/XSLT/html/libxslt-security.html#xsltSetCtxtSecurityPrefs
Previous Comments:
[2010-08-06 18:58:02] lsm...@php.net
some additional infos from Dave Beckett:
but anyway, more info at
http://bugs.librdf.org/mantis/view.php?id=379
I found I could duplicate the error and as I suspected if I made raptor
skip
over xsltSetSecurityPrefs() and xsltSetDefaultSecurityPrefs() calls,
the
program works as expected.
I can probably patch raptor to fix this, then patch the librdf-php to
use that
fix, but that's quite indirect.
Seems all libxslt users in the same memory space will have this issue.
[2010-08-06 15:35:38] lsm...@php.net
to add some more context about the issue, i talked to the author of php
rdf ext
on the #reland freenode IRC channel:
[15:23] lsmith: it's not the php module, it's raptor which
redland uses
[15:23] it sets the libxslt security policy
[15:24] http://librdf.org/raptor/api-1.4/raptor-section-
general.html#raptor-set-libxslt-security-preferences
[15:25] it's hard to do - how is raptor/redland suppose to know
when a
calling application is also wanting to adjust parameters of a shared
library
[15:26] it's the calling app's responsibility - php in this
case
[2010-07-30 10:55:44] penny at liip dot ch
I had exactly the same problem with the following versions:
libxslt1.1 1.1.24-2
php55.2.6.dfsg.1-1+lenny8
php5-librdf 1.0.7.1-1+b1
Purging php5-librdf fixed the problem.
[2010-07-06 00:46:03] matth at mlalonde dot net
Description:
I have been able to replicate under three environment running Ubuntu LTS
php5 (cli, cgi or mod_php), libxslt 1.1.26 and the php5 module and
librdf0 and the php5 module.
With the above setup, any call will
fail with the error
XSLTProcessor::importStylesheet(): Local file read for
/path/to/local/file.xsl refused
Using XSLCache will result in a segfault and no errors.
Removing php5's librdf module fixes the issue.
Test script:
---
# a.php
load($xsl_filename);
$xsl->importStyleSheet($doc);
$doc->load($xml_filename);
echo $xsl->transformToXML($doc);
# collection.xml
Fight for your mind
Ben Harper
1995
Electric Ladyland
Jimi Hendrix
1997
# collection.xsl
http://www.w3.org/1999/XSL/Transform";>
Hey! Welcome to 's sweet CD
collection!
by -
# collection2.xsl
http://www.w3.org/1999/XSL/Transform";>
Hey! Welcome to 's sweet CD
collection!
by00 -
Expected result:
A parsed XSLT document with the imported stylesheets. And no errors ;)
Actual result:
--
Warning: XSLTProcessor::importStylesheet(): error in /var/www/temp/a.php
on line 14
Call Stack:
0.0002 627304 1. {main}() /var/www/temp/a.php:0
0.0006 631128 2. XSLTProcessor->importStylesheet()
/var/www/temp/a.php:14
Warning: XSLTProcessor::importStylesheet(): Local file read for
file:///var/www/pgadmin/temp/collection2.xsl refused in
/var/www/temp/a.php on line 14
Call Stack:
0.0002 627304 1. {main}() /var/www/temp/a.php:0
0.0006 631128 2. XSLTProcessor->importStylesheet()
/var/www/temp/a.php:14
--
Edit this bug report at http://bugs.php.net/bug.php?id=52257&edit=1
#45224 [NEW]: Segmentation Fault in preg_match
From: dave at westphila dot net
Operating system: Linux, Fedora Core 8
PHP version: 5.2.6
PHP Bug Type: Reproducible crash
Bug description: Segmentation Fault in preg_match
Description:
I can reproduce a segfault in a preg_match call with a particular regular
expression and target text (which is a large html file). The offending
regEx and a very similar one which does not segfault are included in the
script I've attached.
Reproduce code:
---
^<]{1,20}>){0,1}(\s|<[^<^>]+>|Â )+L(<[^>^<]{1,20}>){0,1}imitation(\s|<[^<^>]+>|Â )+/";
$exp2 =
"/(<[^>^<]{1,20}>){0,1}(\s|<[^<^>]+>|Â )+L(<[^>^<]{1,20}>){0,1}imitation(\s|<[^<^>]+>|Â )+o/";
preg_match($exp1, $text);
echo "Passed Expression 1\n";
preg_match($exp2, $text);
echo "Passed Expression 2\n";
?>
Expected result:
The file may or may not match the regEx, out of memory maybe, but
certainly it shouldn't segfault.
Actual result:
--
The reg ex string in $exp1 runs ok. The expression in $exp2 is only one
character longer and produces a segfault when run on the file publicly
available here:
http://dev.xtractresearch.com/SD11212006CA.htm
A segfault does not happen when instead of this file a shorter string of
text is used (commented out in the script code). Length of the file should
not be an issue since the first regEx completes ok.
--
Edit bug report at http://bugs.php.net/?id=45224&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45224&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45224&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45224&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45224&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45224&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45224&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45224&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45224&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45224&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45224&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45224&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45224&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45224&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45224&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45224&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45224&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45224&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45224&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45224&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45224&r=mysqlcfg
#40724 [NEW]: srand returns different results in 5.2.1 than in previous versions
From: dave at dmorg dot org Operating system: linux, windows PHP version: 5.2.1 PHP Bug Type: Math related Bug description: srand returns different results in 5.2.1 than in previous versions Description: I use srand to seed random numbers with student id numbers so that whenever students relog in to an assignment, their questions have the same input values and they can continue where they left off. I am now getting different results than before. I'm not sure whether this is an unintended consequence of some apparently unrelated code change or whether it is intended. Reproduce code: --- produces 1387371436 under 4.*, 5.1.1. 5.1.4 produces 1354439493 under 5.2.1 Expected result: I would expect results from the random number generator to be consistent when seeded with the same number Actual result: -- produces 1387371436 under 4.*, 5.1.1. 5.1.4 produces 1354439493 under 5.2.1 -- Edit bug report at http://bugs.php.net/?id=40724&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40724&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40724&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40724&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40724&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40724&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40724&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40724&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40724&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40724&r=support Expected behavior:http://bugs.php.net/fix.php?id=40724&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40724&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40724&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40724&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40724&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40724&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40724&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40724&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40724&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40724&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40724&r=mysqlcfg
#38615 [NEW]: appendXML with xml:id crashes PHP
From: dave at dgx dot cz
Operating system:
PHP version: 5.1.5
PHP Bug Type: DOM XML related
Bug description: appendXML with xml:id crashes PHP
Description:
self-explaining code snippet:
$dom = new DOMDocument();
$dom->loadXML('');
$frag = $dom->createDocumentFragment();
$frag->appendXML('');
// this crashes PHP (cli) 5.1.2 - 5.1.6
$dom->createTextNode("");
--
Edit bug report at http://bugs.php.net/?id=38615&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38615&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38615&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38615&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38615&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38615&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38615&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38615&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38615&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38615&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38615&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38615&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38615&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38615&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38615&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38615&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38615&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38615&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38615&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38615&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38615&r=mysqlcfg
#38615 [Fbk->Opn]: appendXML with xml:id crashes PHP
ID: 38615
User updated by: dave at dgx dot cz
Reported By: dave at dgx dot cz
-Status: Feedback
+Status: Open
Bug Type:DOM XML related
PHP Version: 5.1.5
New Comment:
I've got the same problem with php5.2-win32-latest. Tested with CLI and
Apache 2
Previous Comments:
[2006-08-27 14:17:57] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Can't reproduce...
[2006-08-27 13:46:23] dave at dgx dot cz
Description:
self-explaining code snippet:
$dom = new DOMDocument();
$dom->loadXML('');
$frag = $dom->createDocumentFragment();
$frag->appendXML('');
// this crashes PHP (cli) 5.1.2 - 5.1.6
$dom->createTextNode("");
--
Edit this bug report at http://bugs.php.net/?id=38615&edit=1
#38740 [NEW]: mysqli_stmt::$errno not available
From: dave at psntn dot com Operating system: Linux (SUSE 9.3) PHP version: 6CVS-2006-09-07 (CVS) PHP Bug Type: MySQLi related Bug description: mysqli_stmt::$errno not available Description: When using PHP6.0.0-dev (checked out from CVS, updated in the last 20 mins) the $errno property of mysqli_stmt is not defined. This only happens when unicode.semantics = on. This might be due to the extension not having been upgraded for unicode but I can't quickly find any list of the status of the various extensions. PHP Configure statement: ./configure --prefix=/srv/httpd/php6/php6 --with-apxs2=/srv/httpd/php6/httpd/bin/apxs --with-mysqli=/usr/local/mysql/bin/mysql_config --with-mysql=/usr/local/mysql --with-pear --with-gd --with-png-dir=/usr --enable-gd-native-ttf --with-jpeg-dir=/usr --with-png --with-zlib-dir=/usr --enable-sockets --with-bz2 --with-dom --with-ftp --with-pdf --with-cpdf --with-sqlite --with-freetype-dir=/usr --enable-bcmath --with-tiff-dir=/usr --enable-exif --enable-simplexml --enable-soap --with-zip --enable-mbstring --enable-mbstr-enc-trans --disable-mbregex --with-curl --with-pdo --with-pdo_mysql=/usr/local/mysql/bin/mysql_config php.ini: unicode.semantics = on Reproduce code: --- http://php4.david-salisbury.co.uk/mysqli.phps Expected result: unicode.semantics = off // just to show unicode semantics status Error code for insert of (1, 2, 3, 4): 0 Error code for insert of (1, 5, 6, 7): 1062 Actual result: -- unicode.semantics = on // just to show unicode semantics status Error code for insert of (1, 2, 3, 4): Notice: Undefined property: mysqli_stmt::$errno in /www/testingServer/php6test/mysqli.php on line 31 Error code for insert of (1, 5, 6, 7): Notice: Undefined property: mysqli_stmt::$errno in /www/testingServer/php6test/mysqli.php on line 41 -- Edit bug report at http://bugs.php.net/?id=38740&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38740&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38740&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38740&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38740&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38740&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38740&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38740&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38740&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38740&r=support Expected behavior:http://bugs.php.net/fix.php?id=38740&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38740&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38740&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38740&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38740&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38740&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38740&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38740&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38740&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38740&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38740&r=mysqlcfg
#39067 [NEW]: getDeclaringClass and private attrs
From: dave at dgx dot cz
Operating system:
PHP version: 5.2.0RC5
PHP Bug Type: SPL related
Bug description: getDeclaringClass and private attrs
Description:
ReflectionProperty::getDeclaringClass
Reproduce code:
---
class A {
private $x;
}
class B extends A {
private $x;
}
$rc = new ReflectionClass('B');
echo $rc->getProperty('x')->getDeclaringClass()->getName();
Expected result:
B
Actual result:
--
A
--
Edit bug report at http://bugs.php.net/?id=39067&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39067&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39067&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39067&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39067&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39067&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39067&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39067&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39067&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39067&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39067&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39067&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39067&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39067&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39067&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39067&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39067&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39067&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39067&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39067&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39067&r=mysqlcfg
#39104 [NEW]: ReflectionClass::getMethod and private method
From: dave at dgx dot cz
Operating system:
PHP version: 5.2.0RC5
PHP Bug Type: SPL related
Bug description: ReflectionClass::getMethod and private method
Description:
I'd to like to see 5.2 as first version of PHP, where Reflection works
correctly ;-))
1) ReflectionProperty::getDeclaringClass works good,
ReflectionMethod::getDeclaringClass doesn't.
class Foo {
// ReflectionProperty test
public $prop;
protected function a() {}
protected static function b() {}
public function c() {}
public static function d() {}
}
class Extended extends Foo {
// redeclare all members
public $prop;
protected function a() {}
protected static function b() {}
public function c() {}
public static function d() {}
}
$rc = new ReflectionClass('Extended');
// prints Foo - OK!
echo $rc->getProperty('prop')->getDeclaringClass()->getName();
// prints Extended - ERROR
echo $rc->getMethod('a')->getDeclaringClass()->getName();
echo $rc->getMethod('b')->getDeclaringClass()->getName();
echo $rc->getMethod('c')->getDeclaringClass()->getName();
echo $rc->getMethod('d')->getDeclaringClass()->getName();
2) there still remains bug #37964: Reflection shows private methods of
parent class. Private AND/OR private static
class Foo {
private function a() {}
private static function b() {}
}
class Extended extends Foo {
// there is no method a() or b() in class Extended
}
Extended::b(); // this produces fatal error, OK
$rc = new ReflectionClass('Extended');
$rc->hasMethod('a'); // but this returns TRUE - ERROR
// and this works too, but shouldn't
echo $rc->getMethod('a')->getName();
echo $rc->getMethod('b')->getName();
--
Edit bug report at http://bugs.php.net/?id=39104&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39104&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39104&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39104&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39104&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39104&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39104&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39104&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39104&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39104&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39104&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39104&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39104&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39104&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39104&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39104&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39104&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39104&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39104&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39104&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39104&r=mysqlcfg
#39104 [Fbk->Opn]: ReflectionClass::getMethod and private method
ID: 39104
User updated by: dave at dgx dot cz
Reported By: dave at dgx dot cz
-Status: Feedback
+Status: Open
Bug Type:SPL related
PHP Version: 5.2.0RC5
New Comment:
The behaviour is still the same.
Previous Comments:
[2006-10-10 08:53:46] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-10-10 05:15:42] dave at dgx dot cz
Description:
I'd to like to see 5.2 as first version of PHP, where Reflection works
correctly ;-))
1) ReflectionProperty::getDeclaringClass works good,
ReflectionMethod::getDeclaringClass doesn't.
class Foo {
// ReflectionProperty test
public $prop;
protected function a() {}
protected static function b() {}
public function c() {}
public static function d() {}
}
class Extended extends Foo {
// redeclare all members
public $prop;
protected function a() {}
protected static function b() {}
public function c() {}
public static function d() {}
}
$rc = new ReflectionClass('Extended');
// prints Foo - OK!
echo $rc->getProperty('prop')->getDeclaringClass()->getName();
// prints Extended - ERROR
echo $rc->getMethod('a')->getDeclaringClass()->getName();
echo $rc->getMethod('b')->getDeclaringClass()->getName();
echo $rc->getMethod('c')->getDeclaringClass()->getName();
echo $rc->getMethod('d')->getDeclaringClass()->getName();
2) there still remains bug #37964: Reflection shows private methods of
parent class. Private AND/OR private static
class Foo {
private function a() {}
private static function b() {}
}
class Extended extends Foo {
// there is no method a() or b() in class Extended
}
Extended::b(); // this produces fatal error, OK
$rc = new ReflectionClass('Extended');
$rc->hasMethod('a'); // but this returns TRUE - ERROR
// and this works too, but shouldn't
echo $rc->getMethod('a')->getName();
echo $rc->getMethod('b')->getName();
--
Edit this bug report at http://bugs.php.net/?id=39104&edit=1
#39104 [Bgs]: ReflectionClass::getMethod and private method
ID: 39104
User updated by: dave at dgx dot cz
Reported By: dave at dgx dot cz
Status: Bogus
Bug Type:SPL related
PHP Version: 5.2.0RC5
New Comment:
Expected??
1)
ReflectionProperty::getDeclaringClass()->getName() -> Foo
ReflectionMethod::getDeclaringClass()->getName() -> Extended
Both property and method are declared in Foo and redeclared in
Extended.
2) How can I detect that private method is declared in reflected class,
and not in any parent class?
Previous Comments:
[2006-10-10 10:44:47] [EMAIL PROTECTED]
Expected behaviour.
[2006-10-10 09:52:22] dave at dgx dot cz
The behaviour is still the same.
[2006-10-10 08:53:46] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-10-10 05:15:42] dave at dgx dot cz
Description:
I'd to like to see 5.2 as first version of PHP, where Reflection works
correctly ;-))
1) ReflectionProperty::getDeclaringClass works good,
ReflectionMethod::getDeclaringClass doesn't.
class Foo {
// ReflectionProperty test
public $prop;
protected function a() {}
protected static function b() {}
public function c() {}
public static function d() {}
}
class Extended extends Foo {
// redeclare all members
public $prop;
protected function a() {}
protected static function b() {}
public function c() {}
public static function d() {}
}
$rc = new ReflectionClass('Extended');
// prints Foo - OK!
echo $rc->getProperty('prop')->getDeclaringClass()->getName();
// prints Extended - ERROR
echo $rc->getMethod('a')->getDeclaringClass()->getName();
echo $rc->getMethod('b')->getDeclaringClass()->getName();
echo $rc->getMethod('c')->getDeclaringClass()->getName();
echo $rc->getMethod('d')->getDeclaringClass()->getName();
2) there still remains bug #37964: Reflection shows private methods of
parent class. Private AND/OR private static
class Foo {
private function a() {}
private static function b() {}
}
class Extended extends Foo {
// there is no method a() or b() in class Extended
}
Extended::b(); // this produces fatal error, OK
$rc = new ReflectionClass('Extended');
$rc->hasMethod('a'); // but this returns TRUE - ERROR
// and this works too, but shouldn't
echo $rc->getMethod('a')->getName();
echo $rc->getMethod('b')->getName();
--
Edit this bug report at http://bugs.php.net/?id=39104&edit=1
#39104 [Bgs->Opn]: ReflectionClass::getMethod and private method
ID: 39104
User updated by: dave at dgx dot cz
Reported By: dave at dgx dot cz
-Status: Bogus
+Status: Open
Bug Type:SPL related
PHP Version: 5.2.0RC5
New Comment:
.
Previous Comments:
[2006-10-10 10:51:14] dave at dgx dot cz
Expected??
1)
ReflectionProperty::getDeclaringClass()->getName() -> Foo
ReflectionMethod::getDeclaringClass()->getName() -> Extended
Both property and method are declared in Foo and redeclared in
Extended.
2) How can I detect that private method is declared in reflected class,
and not in any parent class?
[2006-10-10 10:44:47] [EMAIL PROTECTED]
Expected behaviour.
[2006-10-10 09:52:22] dave at dgx dot cz
The behaviour is still the same.
[2006-10-10 08:53:46] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-10-10 05:15:42] dave at dgx dot cz
Description:
I'd to like to see 5.2 as first version of PHP, where Reflection works
correctly ;-))
1) ReflectionProperty::getDeclaringClass works good,
ReflectionMethod::getDeclaringClass doesn't.
class Foo {
// ReflectionProperty test
public $prop;
protected function a() {}
protected static function b() {}
public function c() {}
public static function d() {}
}
class Extended extends Foo {
// redeclare all members
public $prop;
protected function a() {}
protected static function b() {}
public function c() {}
public static function d() {}
}
$rc = new ReflectionClass('Extended');
// prints Foo - OK!
echo $rc->getProperty('prop')->getDeclaringClass()->getName();
// prints Extended - ERROR
echo $rc->getMethod('a')->getDeclaringClass()->getName();
echo $rc->getMethod('b')->getDeclaringClass()->getName();
echo $rc->getMethod('c')->getDeclaringClass()->getName();
echo $rc->getMethod('d')->getDeclaringClass()->getName();
2) there still remains bug #37964: Reflection shows private methods of
parent class. Private AND/OR private static
class Foo {
private function a() {}
private static function b() {}
}
class Extended extends Foo {
// there is no method a() or b() in class Extended
}
Extended::b(); // this produces fatal error, OK
$rc = new ReflectionClass('Extended');
$rc->hasMethod('a'); // but this returns TRUE - ERROR
// and this works too, but shouldn't
echo $rc->getMethod('a')->getName();
echo $rc->getMethod('b')->getName();
--
Edit this bug report at http://bugs.php.net/?id=39104&edit=1
#39104 [Bgs]: ReflectionClass::getMethod and private method
ID: 39104 User updated by: dave at dgx dot cz Reported By: dave at dgx dot cz Status: Bogus Bug Type:SPL related PHP Version: 5.2.0RC5 New Comment: > And there is a big difference if a public method gets redeclared, because it would be executed in the scope of the class where it was executed. Thank you for explain Tony, it makes sense. Previous Comments: [2006-10-13 10:45:20] [EMAIL PROTECTED] >ReflectionProperty::getDeclaringClass()->getName() -> Foo >ReflectionMethod::getDeclaringClass()->getName() -> Extended >Both property and method are declared in Foo and >redeclared in Extended. There is no difference whether a public property was declared in the parent or in the child - in both cases it exists in the lists of properties of both classes. And there is a big difference if a public method gets redeclared, because it would be executed in the scope of the class where it was executed. This scope is used as the "declaring class". So it is expected, yes. The second problem is assigned to me, no need to create another report about it. ---- [2006-10-13 06:59:01] dave at dgx dot cz . ---- [2006-10-10 10:51:14] dave at dgx dot cz Expected?? 1) ReflectionProperty::getDeclaringClass()->getName() -> Foo ReflectionMethod::getDeclaringClass()->getName() -> Extended Both property and method are declared in Foo and redeclared in Extended. 2) How can I detect that private method is declared in reflected class, and not in any parent class? [2006-10-10 10:44:47] [EMAIL PROTECTED] Expected behaviour. ---- [2006-10-10 09:52:22] dave at dgx dot cz The behaviour is still the same. 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/39104 -- Edit this bug report at http://bugs.php.net/?id=39104&edit=1
#39304 [NEW]: Segmentation fault with list unpacking of string offset
From: dave at ramenlabs dot com
Operating system: Linux
PHP version: 5CVS-2006-10-30 (CVS)
PHP Bug Type: Reproducible crash
Bug description: Segmentation fault with list unpacking of string offset
Description:
In a function expecting an array parameter, I accidentally passed in a
string instead. For some reason related to the particular way I used list
unpacking of an array offset, it caused PHP to crash with a segmentation
fault.
I have observed this problem in PHP 4.4.2 as well as PHP 5, freshly
downloaded and compiled from CVS.
Reproduce code:
---
Expected result:
Fatal error: Cannot use string offset as an array
Actual result:
--
Segmentation fault
[EMAIL PROTECTED]:~/tmp/php5/sapi/cli$ echo '' | php
Segmentation fault (core dumped)
[EMAIL PROTECTED]:~/tmp/php5/sapi/cli$ gdb ./php core
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
#0 0x082b8429 in ZEND_SR_SPEC_VAR_VAR_HANDLER (execute_data=0xbfcf925c)
at /home/ramen/tmp/php5/Zend/zend_vm_execute.h:11516
11516 shift_right_function(&EX_T(opline->result.u.var).tmp_var,
(gdb) bt
#0 0x082b8429 in ZEND_SR_SPEC_VAR_VAR_HANDLER (execute_data=0xbfcf925c)
at /home/ramen/tmp/php5/Zend/zend_vm_execute.h:11516
#1 0x082a1a98 in zif_each (ht=140604596, return_value=0x851b960,
return_value_ptr=0x20, this_ptr=0xbfcf9370, return_value_used=4)
at /home/ramen/tmp/php5/Zend/zend_builtin_functions.c:417
#2 0x082821ee in zend_u_str_tolower_dup (type=0 '\0', source=
{s = 0xbfcfb674 "\002", u = 0xbfcfb674, v = 0xbfcfb674},
length=139127824) at /home/ramen/tmp/php5/Zend/zend_operators.c:2384
#3 0x08240352 in php_module_startup (sf=0xbfcfb674,
additional_modules=0x83112d0, num_additional_modules=139120832)
at /home/ramen/tmp/php5/main/main.c:1554
#4 0x08311219 in ZEND_SL_SPEC_CONST_VAR_HANDLER (execute_data=0x0)
at /home/ramen/tmp/php5/Zend/zend_execute.c:78
#5 0xb79ceea8 in ?? ()
#6 0x in ?? ()
(gdb)
--
Edit bug report at http://bugs.php.net/?id=39304&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39304&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39304&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39304&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39304&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39304&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39304&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39304&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39304&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39304&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39304&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39304&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39304&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39304&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39304&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39304&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39304&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39304&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39304&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39304&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39304&r=mysqlcfg
#39304 [Opn]: Segmentation fault with list unpacking of string offset
ID: 39304 User updated by: dave at ramenlabs dot com Reported By: dave at ramenlabs dot com Status: Open Bug Type: Reproducible crash Operating System: Linux PHP Version: 5CVS-2006-10-30 (CVS) New Comment: I accidentally generated that backtrace using my system-installed version of PHP. Here's a correct backtrace: [EMAIL PROTECTED]:~/tmp/php5/sapi/cli$ echo '' | ./php Segmentation fault (core dumped) [EMAIL PROTECTED]:~/tmp/php5/sapi/cli$ gdb ./php ./core GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". warning: Can't read pathname for load map: Input/output error. Reading symbols from /lib/tls/libcrypt.so.1...done. Loaded symbols for /lib/tls/libcrypt.so.1 Reading symbols from /lib/tls/librt.so.1...done. Loaded symbols for /lib/tls/librt.so.1 Reading symbols from /lib/tls/libresolv.so.2...done. Loaded symbols for /lib/tls/libresolv.so.2 Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/tls/libdl.so.2...done. Loaded symbols for /lib/tls/libdl.so.2 Reading symbols from /lib/tls/libnsl.so.1...done. Loaded symbols for /lib/tls/libnsl.so.1 Reading symbols from /usr/lib/libicui18n.so.34...done. Loaded symbols for /usr/lib/libicui18n.so.34 Reading symbols from /usr/lib/libicuuc.so.34...done. Loaded symbols for /usr/lib/libicuuc.so.34 Reading symbols from /usr/lib/libicudata.so.34... warning: Lowest section in /usr/lib/libicudata.so.34 is .hash at 0094 done. Loaded symbols for /usr/lib/libicudata.so.34 Reading symbols from /usr/lib/libicuio.so.34...done. Loaded symbols for /usr/lib/libicuio.so.34 Reading symbols from /usr/lib/libxml2.so.2...done. Loaded symbols for /usr/lib/libxml2.so.2 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/tls/libpthread.so.0...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Core was generated by `./php'. Program terminated with signal 11, Segmentation fault. #0 0x082c6839 in ZEND_FETCH_DIM_R_SPEC_VAR_CONST_HANDLER ( execute_data=0xbfb6e090) at /home/ramen/tmp/php5/Zend/zend_vm_execute.h:9034 9034 PZVAL_LOCK(*EX_T(opline->op1.u.var).var.ptr_ptr); (gdb) bt #0 0x082c6839 in ZEND_FETCH_DIM_R_SPEC_VAR_CONST_HANDLER ( execute_data=0xbfb6e090) at /home/ramen/tmp/php5/Zend/zend_vm_execute.h:9034 #1 0x082b0308 in execute (op_array=0xb70904fc) at /home/ramen/tmp/php5/Zend/zend_vm_execute.h:92 #2 0x0828b5dc in zend_execute_scripts (type=8, retval=, file_count=3) at /home/ramen/tmp/php5/Zend/zend.c:1616 #3 0x0823f4c0 in php_execute_script (primary_file=0xbfb704d0) at /home/ramen/tmp/php5/main/main.c:1922 #4 0x08312a95 in main (argc=1, argv=0xbfb705d4) at /home/ramen/tmp/php5/sapi/cli/php_cli.c:1119 (gdb) Previous Comments: [2006-10-30 08:03:04] dave at ramenlabs dot com Description: In a function expecting an array parameter, I accidentally passed in a string instead. For some reason related to the particular way I used list unpacking of an array offset, it caused PHP to crash with a segmentation fault. I have observed this problem in PHP 4.4.2 as well as PHP 5, freshly downloaded and compiled from CVS. Reproduce code: --- Expected result: Fatal error: Cannot use string offset as an array Actual result: -- Segmentation fault [EMAIL PROTECTED]:~/tmp/php5/sapi/cli$ echo '' | php Segmentation fault (core dumped) [EMAIL PROTECTED]:~/tmp/php5/sapi/cli$ gdb ./php core GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `php'. Program terminate
#37637 [NEW]: Can't access file via file://
From: dave at dgx dot cz
Operating system:
PHP version: 5.1.4
PHP Bug Type: PCRE related
Bug description: Can't access file via file://
Description:
Too long input string crashes PHP:
Reproduce code:
---
// in some situation 400 chars is enought to reproduce error
$s = str_repeat('*', 5000);
preg_match_all('#(\*)+#', $s, $matches);
Actual result:
--
4.3.10 crash
4.3.11 crash
4.3.3 crash
4.3.4 crash
4.3.5 crash
4.3.6 crash
4.3.7 crash
4.3.8 crash
4.3.9 crash
4.4.0 crash
4.4.1 crash
4.4.2 crash
5.0.0 OK
5.0.1 OK
5.0.2 OK
5.0.3 OK
5.0.4 OK
5.0.5 OK
5.1.1 OK
5.1.2 OK
5.1.3 crash
5.1.4 crash
--
Edit bug report at http://bugs.php.net/?id=37637&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37637&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37637&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37637&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37637&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37637&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37637&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37637&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37637&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37637&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37637&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37637&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37637&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37637&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37637&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37637&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37637&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37637&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37637&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37637&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37637&r=mysqlcfg
#37637 [Opn]: Can't access file via file://
ID: 37637
User updated by: dave at dgx dot cz
Reported By: dave at dgx dot cz
Status: Open
Bug Type:PCRE related
PHP Version: 5.1.4
New Comment:
summary: Too long input string crashes PHP:
Previous Comments:
[2006-05-30 06:21:23] dave at dgx dot cz
Description:
Too long input string crashes PHP:
Reproduce code:
---
// in some situation 400 chars is enought to reproduce error
$s = str_repeat('*', 5000);
preg_match_all('#(\*)+#', $s, $matches);
Actual result:
--
4.3.10 crash
4.3.11 crash
4.3.3 crash
4.3.4 crash
4.3.5 crash
4.3.6 crash
4.3.7 crash
4.3.8 crash
4.3.9 crash
4.4.0 crash
4.4.1 crash
4.4.2 crash
5.0.0 OK
5.0.1 OK
5.0.2 OK
5.0.3 OK
5.0.4 OK
5.0.5 OK
5.1.1 OK
5.1.2 OK
5.1.3 crash
5.1.4 crash
--
Edit this bug report at http://bugs.php.net/?id=37637&edit=1
#37637 [Fbk->Opn]: Can't access file via file://
ID: 37637
User updated by: dave at dgx dot cz
-Summary: Too long input string crashes PHP
Reported By: dave at dgx dot cz
-Status: Feedback
+Status: Open
Bug Type:PCRE related
PHP Version: 5.1.4
New Comment:
Windows XP SP2
Previous Comments:
[2006-05-30 09:01:09] [EMAIL PROTECTED]
Also please let us know what OS are you using.
[2006-05-30 08:03:31] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
Can't reproduce nor with 5000 of *'s, neither with 5 000 000.
[2006-05-30 06:33:54] dave at dgx dot cz
summary: Too long input string crashes PHP:
[2006-05-30 06:21:23] dave at dgx dot cz
Description:
Too long input string crashes PHP:
Reproduce code:
---
// in some situation 400 chars is enought to reproduce error
$s = str_repeat('*', 5000);
preg_match_all('#(\*)+#', $s, $matches);
Actual result:
--
4.3.10 crash
4.3.11 crash
4.3.3 crash
4.3.4 crash
4.3.5 crash
4.3.6 crash
4.3.7 crash
4.3.8 crash
4.3.9 crash
4.4.0 crash
4.4.1 crash
4.4.2 crash
5.0.0 OK
5.0.1 OK
5.0.2 OK
5.0.3 OK
5.0.4 OK
5.0.5 OK
5.1.1 OK
5.1.2 OK
5.1.3 crash
5.1.4 crash
--
Edit this bug report at http://bugs.php.net/?id=37637&edit=1
#37773 [NEW]: Can't access file via file://
From: dave at dgx dot cz Operating system: PHP version: 5.1.4 PHP Bug Type: ICONV related Bug description: Can't access file via file:// Description: (Similar to bug #34757). When input string length = 1, iconv_substr() produces "Unknown error (0)" and returns FALSE. Reproduce code: --- $s = 'x'; $s = iconv_substr($s, 0, 1, 'UTF-8'); var_dump($s); Expected result: string(1) "x" Actual result: -- bool(false) and Notice: iconv_substr() [function.iconv-substr.html]: Unknown error (0) in ... -- Edit bug report at http://bugs.php.net/?id=37773&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37773&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37773&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37773&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37773&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37773&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37773&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37773&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37773&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37773&r=support Expected behavior:http://bugs.php.net/fix.php?id=37773&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37773&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37773&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37773&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37773&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37773&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37773&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37773&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37773&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37773&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37773&r=mysqlcfg
#37773 [Opn]: Can't access file via file://
ID: 37773 User updated by: dave at dgx dot cz Reported By: dave at dgx dot cz Status: Open Bug Type:ICONV related PHP Version: 5.1.4 New Comment: Of course, title is: iconv_substr() gives "Unknown error" when string length = 1" Operating system: Windows XP. It is not my error - bugs.php.net has bugs! Previous Comments: [2006-06-10 00:01:14] dave at dgx dot cz Description: (Similar to bug #34757). When input string length = 1, iconv_substr() produces "Unknown error (0)" and returns FALSE. Reproduce code: --- $s = 'x'; $s = iconv_substr($s, 0, 1, 'UTF-8'); var_dump($s); Expected result: string(1) "x" Actual result: -- bool(false) and Notice: iconv_substr() [function.iconv-substr.html]: Unknown error (0) in ... -- Edit this bug report at http://bugs.php.net/?id=37773&edit=1
#37851 [NEW]: Unable to load dynamic library should say where it looked
From: Dave at Yost dot com Operating system: linux PHP version: 5.1.4 PHP Bug Type: Dynamic loading Bug description: Unable to load dynamic library should say where it looked Description: Error message is not helpful. A good error message could save thousands of hours of people's time worldwide. Expected result: Unable to load dynamic library './mysql.so' - ./mysql.so: cannot open shared object file: No such file or directory in '/usr/lb', '/lib,', '/usr/local/apache/php/extensions'. Change blah in php.ini or recompile with the -with-blah=foo' option to fix this problem. Actual result: -- Unable to load dynamic library './mysql.so' - ./mysql.so: cannot open shared object file: No such file or directory And "Incorrect CAPTCHA" at the top of this bug reporting page should instead be red text next to the thing that is wrong. Not everyone knows right away what CAPTCHA is. -- Edit bug report at http://bugs.php.net/?id=37851&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37851&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37851&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37851&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37851&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37851&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37851&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37851&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37851&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37851&r=support Expected behavior:http://bugs.php.net/fix.php?id=37851&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37851&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37851&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37851&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37851&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37851&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37851&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37851&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37851&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37851&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37851&r=mysqlcfg
#38000 [NEW]: preg_match fails if strlen >= 1630
From: dave at smartboy dot com
Operating system: Windows XP
PHP version: 5.1.4
PHP Bug Type: PCRE related
Bug description: preg_match fails if strlen >= 1630
Description:
preg_match() with regexp to test for valid UTF-8 sequence - fails and
causes the error message:
'Could not open input file: .php'
IF the subject string passed to preg_match() is longer than 1629
characters. (Or in this case the size of the file 'zzz' which contains
ASCII)
There was no such limitation in preg_match() in the previous version of
PHP (5.1.2)
Reproduce code:
---
$str = file_get_contents('zzz');
echo "Loaded file...\n";
$result =
preg_match('/^([\x00-\x7f]|[\xc2-\xdf][\x80-\xbf]|\xe0[\xa0-\xbf][\x80-\xbf]|'
.
'[\xe1-\xec][\x80-\xbf]{2}|\xed[\x80-\x9f][\x80-\xbf]|[\xee-\xef][\x80-\xbf]{2}|'
.
'\xf0[\x90-\xbf][\x80-\xbf]{2}|[\xf1-\xf3][\x80-\xbf]{3}|\xf4[\x80-\x8f][\x80-\xbf]{2})*$/S',
$str) === 1;
echo "Back from preg_match()\n";
var_export($result);
echo "\n";
Expected result:
Loaded file...
Back from preg_match()
true
Actual result:
--
Loaded file...
Could not open input file: u8.php
--
Edit bug report at http://bugs.php.net/?id=38000&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38000&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38000&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38000&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38000&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38000&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38000&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38000&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38000&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38000&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38000&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38000&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38000&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38000&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38000&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38000&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38000&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38000&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38000&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38000&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38000&r=mysqlcfg
#38000 [Fbk->Opn]: preg_match fails if strlen >= 1630
ID: 38000
User updated by: dave at smartboy dot com
Reported By: dave at smartboy dot com
-Status: Feedback
+Status: Open
Bug Type: PCRE related
Operating System: Windows XP
PHP Version: 5.1.4
New Comment:
It turns out that no test file is needed
$str = str_repeat('a', 1575); //works
$str = str_repeat('a', 1576); //fails
There are really two issues:
- PCRE not working for "long" strings (although 1576 bytes is not
really a "long" string). This greatly limits the usefulness of regexp
pattern matching.
- When PCRE fails the error message is VERY misleading. Surely an
E_NOTICE should be issued by preg_match() if match has failed due to
out of memory, etc.? "Could not open input file" is just plain wrong.
Previous Comments:
[2006-07-04 14:40:01] [EMAIL PROTECTED]
please provide the zzz file. (either post a link to it or send it to my
e-mail).
----
[2006-07-04 00:46:02] dave at smartboy dot com
Description:
preg_match() with regexp to test for valid UTF-8 sequence - fails and
causes the error message:
'Could not open input file: .php'
IF the subject string passed to preg_match() is longer than 1629
characters. (Or in this case the size of the file 'zzz' which contains
ASCII)
There was no such limitation in preg_match() in the previous version of
PHP (5.1.2)
Reproduce code:
---
$str = file_get_contents('zzz');
echo "Loaded file...\n";
$result =
preg_match('/^([\x00-\x7f]|[\xc2-\xdf][\x80-\xbf]|\xe0[\xa0-\xbf][\x80-\xbf]|'
.
'[\xe1-\xec][\x80-\xbf]{2}|\xed[\x80-\x9f][\x80-\xbf]|[\xee-\xef][\x80-\xbf]{2}|'
.
'\xf0[\x90-\xbf][\x80-\xbf]{2}|[\xf1-\xf3][\x80-\xbf]{3}|\xf4[\x80-\x8f][\x80-\xbf]{2})*$/S',
$str) === 1;
echo "Back from preg_match()\n";
var_export($result);
echo "\n";
Expected result:
Loaded file...
Back from preg_match()
true
Actual result:
--
Loaded file...
Could not open input file: u8.php
--
Edit this bug report at http://bugs.php.net/?id=38000&edit=1
#38000 [Opn]: preg_match fails if strlen >= 1630
ID: 38000
User updated by: dave at smartboy dot com
Reported By: dave at smartboy dot com
Status: Open
Bug Type: PCRE related
Operating System: Windows XP
PHP Version: 5.1.4
New Comment:
$str = str_repeat('a', 100); //works in PHP 5.1.2
Previous Comments:
[2006-07-04 21:23:49] dave at smartboy dot com
It turns out that no test file is needed
$str = str_repeat('a', 1575); //works
$str = str_repeat('a', 1576); //fails
There are really two issues:
- PCRE not working for "long" strings (although 1576 bytes is not
really a "long" string). This greatly limits the usefulness of regexp
pattern matching.
- When PCRE fails the error message is VERY misleading. Surely an
E_NOTICE should be issued by preg_match() if match has failed due to
out of memory, etc.? "Could not open input file" is just plain wrong.
[2006-07-04 14:40:01] [EMAIL PROTECTED]
please provide the zzz file. (either post a link to it or send it to my
e-mail).
[2006-07-04 00:46:02] dave at smartboy dot com
Description:
preg_match() with regexp to test for valid UTF-8 sequence - fails and
causes the error message:
'Could not open input file: .php'
IF the subject string passed to preg_match() is longer than 1629
characters. (Or in this case the size of the file 'zzz' which contains
ASCII)
There was no such limitation in preg_match() in the previous version of
PHP (5.1.2)
Reproduce code:
---
$str = file_get_contents('zzz');
echo "Loaded file...\n";
$result =
preg_match('/^([\x00-\x7f]|[\xc2-\xdf][\x80-\xbf]|\xe0[\xa0-\xbf][\x80-\xbf]|'
.
'[\xe1-\xec][\x80-\xbf]{2}|\xed[\x80-\x9f][\x80-\xbf]|[\xee-\xef][\x80-\xbf]{2}|'
.
'\xf0[\x90-\xbf][\x80-\xbf]{2}|[\xf1-\xf3][\x80-\xbf]{3}|\xf4[\x80-\x8f][\x80-\xbf]{2})*$/S',
$str) === 1;
echo "Back from preg_match()\n";
var_export($result);
echo "\n";
Expected result:
Loaded file...
Back from preg_match()
true
Actual result:
--
Loaded file...
Could not open input file: u8.php
--
Edit this bug report at http://bugs.php.net/?id=38000&edit=1
