#35368 [Com]: PDO query does not work properly with serialize
ID: 35368 Comment by: ET at 126 dot COM Reported By: lists at cyberlot dot net Status: Suspended Bug Type: PDO related Operating System: * PHP Version: 6CVS, 5CVS Assigned To: wez New Comment: a href=http://www.baidu.com;baidu/a [url=www.google.com]google[/url] [url=http://www.sina.com]sina[/url] [url=http://www.baidu.com]baidu[/url] [link=http://www.yahoo.com]yahoo[/link] Previous Comments: [2009-10-24 00:53:35] linlixiang123 at 126 dot com As there are number of ways by which a href=http://www.jordanshoes100.com;jordan shoes/a your hair, but you will find using hair straightener easy. a href=http://www.jordanshoes100.com;air jordan shoes/a Today something that no person will be without is his or her a href=http://www.jordanshoes100.com;cheap jordan shoes/a .Since hair straightener has become an essential part of so it is wise to check that they are in good condition and do not need replacing if you have had your. [2005-11-27 22:11:06] w...@php.net We managed to reproduce the problem; it's a problem with the query rewriter when it maps :name to ?. If the string is embedded in the SQL using single quotes, but has double quotes backslashed, the string it too tricky for the parser to follow, and it ends up transforming parts of the serialized string that it shouldn't. There are three possible workarounds for this issue, in order of preference: - Don't embed serialized data into the query string; use bound parameters (that's what they're there for). In future versions of PDO, prepared statements may be cacheable in persistent connections, leading to a performance gain. - Use PDO::quote() to correctly quote the string - Use PDO::exec() to fire off this UPDATE/INSERT statement; it uses an alternate API that doesn't need to handle parameters. [2005-11-25 16:40:35] tony2...@php.net This is fixed in CVS, get a fresh snapshot and try again. [2005-11-25 16:32:07] lists at cyberlot dot net To try and narrow this down and be able to play with the code more I recompiled PHP 5.1 without pdo support then compiled seperate modules however I could not get pdo_mysql to compile. I phpized ./configure and make and get the following error checking for MySQL support for PDO... yes, shared checking for mysql_config... /usr/bin/mysql_config checking for mysql_query... no configure: error: mysql_query missing!? Might be related? So I forced a install of pdo_mysql RC2 The bug goes away, Same exact script but everything is working... So its either a diffrence between pdo_mysql RC2 or some wierd issue with shared vs compiled in. I hope that helps somehow? [2005-11-25 15:14:33] lists at cyberlot dot net What OS are you testing on? All I have are Centos/Redhat based boxes to test on. Also if this helps I always download directly from MySQL I never use the DIST included rpms. 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/35368 -- Edit this bug report at http://bugs.php.net/?id=35368edit=1
#48547 [Com]: DirectoryIterator Slash issue with getPathname Windows with Apache
ID: 48547
Comment by: webmaster at asylum-et dot cm
Reported By: BinaryKitten at jkrswebsolutions dot co dot uk
Status: Open
Bug Type: SPL related
Operating System: XP SP3
PHP Version: 5.2.9
New Comment:
I have tested this on Windows XP SP3 with PHP 5.2.5 and have the same
findings as BinaryKitten at jkrswebsolutions dot co dot uk
Previous Comments:
[2009-06-14 11:47:49] BinaryKitten at jkrswebsolutions dot co dot uk
Description:
When using the DirectoryIterator to go through files/folders on Windows
under apache, the path has a mismatch of \ and /
Reproduce code:
---
?php
$dir = new DirectoryIterator( $_SERVER['DOCUMENT_ROOT'] );
echo strong.$dir-getPath()./strongbr /;
foreach($dir as $file ) {
$dirName = $file-getPathname();
echo $dirName.br /;
}
?
Expected result:
With the Document root as C:\HTDOCS Apache returns
$_SERVER['DOCUMENT_ROOT'] as c:/HTDOCS
Expected Output
C:/HTDOCS/.
C:/HTDOCS/..
C:/HTDOCS/css
C:/HTDOCS/index.php
C:/HTDOCS/js
C:/HTDOCS/
Actual result:
--
C:/HTDOCS\.
C:/HTDOCS\..
C:/HTDOCS\css
C:/HTDOCS\index.php
C:/HTDOCS\js
--
Edit this bug report at http://bugs.php.net/?id=48547edit=1
#45523 [NEW]: max_execution_time not working as documented
From: webmaster at asylum-et dot com Operating system: Any PHP version: 5.2.6 PHP Bug Type: *General Issues Bug description: max_execution_time not working as documented Description: I have found an old bug that I have found twice and has been closed twice claiming it is fixed. Bugs #37306 and #37408. This has not been fixed. I have found this issue in bug threads dating back as far as 2006. I have PHP 5.2.5.5 / WinXP SP2 / Apache 2.2.4.0 and PHP is NOT in safe mode. I get the error message Fatal error: Maximum execution time of 0 seconds exceeded ... Reproduce code: --- The max_execution_time was set to 0 to allow infinite time since 120 was not enough and had been the previous setting. Come to find out 120 was ample but this bug showed its face. According to the PHP.net documentation, The maximum execution time, in seconds. If set to zero, no time limit is imposed. Previous note in the other report was closed due to no one being able to recreate this error. I have installed this version of PHP 4 times with the exact same result so it should be rather simple to recreate since I have 4 times already. Hopefully this receives an honest attempt at resolving the bug. I would give more info but there is nothing else except that I see the error when trying to upload files of only 6 MB. Expected result: max_execution_time = 0 to work as documented Actual result: -- Scripts fail unless setting max_input_time = 0 as well -- Edit bug report at http://bugs.php.net/?id=45523edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45523r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45523r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45523r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45523r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45523r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45523r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45523r=needscript Try newer version:http://bugs.php.net/fix.php?id=45523r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45523r=support Expected behavior:http://bugs.php.net/fix.php?id=45523r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45523r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45523r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45523r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45523r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45523r=dst IIS Stability:http://bugs.php.net/fix.php?id=45523r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45523r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45523r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45523r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45523r=mysqlcfg
#41401 [Bgs-Opn]: Order of Operations error on divide by negative
ID: 41401 Updated by: [EMAIL PROTECTED] Reported By: drlippman at yahoo dot com -Status: Bogus +Status: Open Bug Type: Math related Operating System: Windows, Linux PHP Version: 4.4.7 New Comment: This IS a bug. http://de.php.net/operators lists unary - having higher precedence than the arithmetic operators, and that is the way it should be. So, this statement should evaluate to 1/(-2)*5 and that is -2.5 and not -0.1. Previous Comments: [2007-05-16 12:50:59] [EMAIL PROTECTED] Sorry, but 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 as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. [2007-05-15 15:44:07] drlippman at yahoo dot com Description: Left-to-right order of operations does not appear to be honored when dividing by a negative Reproduce code: --- 1/-2*5 Expected result: -2.5 Actual result: -- -.1 -- Edit this bug report at http://bugs.php.net/?id=41401edit=1
#37336 [Opn-Bgs]: base64_encode/decode bug
ID: 37336 Updated by: [EMAIL PROTECTED] Reported By: cryogen at mac dot com -Status: Open +Status: Bogus Bug Type: *Encryption and hash functions Operating System: Mac OS X 10.4.6 PHP Version: 5.1.4 New Comment: If you are using the function like in your code example, there is no bug. base64 uses + as one of the encoded characters. When passing + in a query string, it will result in a space, and if you decode a base64 string where all + have been replaced with a space, it is obvious that the result will be different. Use (raw)urlencode on the result before putting it into a hyperlink. Notes: a) base64_encode is NOT an encryption or hashing function. b) If you have that code somewhere on the freely accessible web, you really should read about SQL Injection. Previous Comments: [2006-05-06 17:21:50] cryogen at mac dot com The reproduce code I put in my original post is the functioning example. It represents 2 short scripts. Each script start with two lines of comments. Just paste those into your editor and save each one using the script name found on the first comment line. It should be fairly easy to test using the provided script to see the results. [2006-05-06 09:12:18] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-05-06 00:19:47] cryogen at mac dot com Description: I have been using base64_encode/decode for the past 2 years to pass complex SQL statements in href links between scripts running under php 5.0.4. After upgrading to 5.1.2 I experienced errors and missing data using the same functions. I get the same results in php 5.1.4. It appears that data is being lost or garbled in either the encode or decode. This problem does NOT occur on our production server running 5.0.4. NOTE: Unable to post code to reproduced bug on production server as we cannot install 5.1.x if there is a problem. I tried to keep it as short as possible and illustrate the bug. Reproduce code: --- // base64_bug1.php - Demo bug with base64_encode/decode //-- $query = SELECT DISTINCT class.class_no, class.status, class.class_id, class.sess_group, class.short_desc, class.classroom, class.ages, class.capacity, csc.beg_date, csc.end_date, csc.end_date_infinite_flag, csc.open_sched_flag, ins.lname, ins.fname, CONCAT(ins.fname,' ',ins.lname) AS ins_full_name, csc.w_mon, csc.w_mon_time, csc.w_mon_duration, csc.w_tue, csc.w_tue_time, csc.w_tue_duration, csc.w_wed, csc.w_wed_time, csc.w_wed_duration, csc.w_thu, csc.w_thu_time, csc.w_thu_duration, csc.w_fri, csc.w_fri_time, csc.w_fri_duration, csc.w_sat, csc.w_sat_time, csc.w_sat_duration, csc.w_sun, csc.w_sun_time, csc.w_sun_duration FROM class_sched_cfg AS csc, class LEFT JOIN class_sched AS cs ON class.class_id = cs.class_id LEFT JOIN class_instruct AS ci ON (class.class_id = ci.class_id AND ci.primary_ins_flag = 1) LEFT JOIN instructor AS ins ON ci.ins_id = ins.ins_id WHERE class.co_id = 5 AND class.class_id = csc.class_id AND (((cs.beg_time '01:00:00' AND cs.beg_time '23:00:00') OR (cs.end_time '01:00:00' AND cs.end_time '23:00:00')) OR (cs.beg_time = '01:00:00' AND cs.end_time = '23:00:00')) AND sess_group LIKE 'spring/summer%' AND (class.status = 'A' AND CURDATE() = csc.end_date) ORDER by short_desc; $tmp = base64_encode($query); echo a href='base64_bug2.php?query=.$tmp.'Pass Data/a; ? // base64_bug2.php - Demo bug with base64_encode/decode //-- echo bWe should get our original encoded Value back.br/Encoded Value Prior to base64_decode:/bbr/ .$_REQUEST['query']; $query = base64_decode($_REQUEST['query']); echo pbValue After base64_decode:/bbr/ .$query; echo pa href='encode_bug1.php'Back to Step 1/a; ? Expected result: I should have gotten my original SQL string back after executing the base64_decode(). I get part of the string back with the last couple lines garbled with crazy characters. Actual result: -- I get part of the original string back with the last couple lines garbled with crazy characters. Here is the actual output from script base64_bu2.php: SELECT DISTINCT class.class_no, class.status, class.class_id, class.sess_group, class.short_desc, class.classroom, class.ages, class.capacity, csc.beg_date, csc.end_date, csc.end_date_infinite_flag,
#37336 [Bgs]: base64_encode/decode bug
ID: 37336 Updated by: [EMAIL PROTECTED] Reported By: cryogen at mac dot com Status: Bogus Bug Type: *Encryption and hash functions Operating System: Mac OS X 10.4.6 PHP Version: 5.1.4 New Comment: Right, something changed. Whitespace was not properly ignored before, see bug #34214. The solution to your problem is simply urlencoding the value, like you should with any value that you pass via hyperlinks that could contain special characters (like +). Previous Comments: [2006-05-06 18:58:44] cryogen at mac dot com Quick Followup: I echo'd the base64_encode of the string to see if their were any embedded + characters and do indeed see one about 4/5 of the way through the encoded string. This may be the problem. But, if this is indeed my problem, why does this same script work under PHP 5.0.4? Something has changed in the base64_endode() function. Since we use this type of code in dozens of places throughout our online product, it will be difficult and expensiver to track down and fix all of them. [2006-05-06 18:45:39] cryogen at mac dot com Thanks for your quick response. As I mentioned in my post, i have been using the same code for 2+ years and it only stopped functioning after upgrading php to 5.1.x, while it continues to work without a problem in 5.0.4. Since I do not base64_encode any + characters in my strings, this is not the issue. Please look at the garbled text in my results from my original post. It is not simply an issue of getting back space characters for plus signs in the original string (since there are none) but in my example the last 60 or so characters of the original string are garbage. And again running the exact two scripts under PHP 5.0.4 correctly base64_encodes and decodes the string properly. Please look further into this. So something has changed between version 5.0.4 and 5.1.x in those functions. Thanks for the support. [2006-05-06 17:51:54] [EMAIL PROTECTED] If you are using the function like in your code example, there is no bug. base64 uses + as one of the encoded characters. When passing + in a query string, it will result in a space, and if you decode a base64 string where all + have been replaced with a space, it is obvious that the result will be different. Use (raw)urlencode on the result before putting it into a hyperlink. Notes: a) base64_encode is NOT an encryption or hashing function. b) If you have that code somewhere on the freely accessible web, you really should read about SQL Injection. [2006-05-06 17:21:50] cryogen at mac dot com The reproduce code I put in my original post is the functioning example. It represents 2 short scripts. Each script start with two lines of comments. Just paste those into your editor and save each one using the script name found on the first comment line. It should be fairly easy to test using the provided script to see the results. [2006-05-06 09:12:18] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. 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/37336 -- Edit this bug report at http://bugs.php.net/?id=37336edit=1
#33982 [NEW]: add functionality for gmp_nextprime (includes patch)
From: korte-php at et dot ruhr-uni-bochum dot de Operating system: Linux PHP version: 4.4.0 PHP Bug Type: Math related Bug description: add functionality for gmp_nextprime (includes patch) Description: In order to use the php-gmp functions for cryptographic purposes, having mpz_nextprime ist sort of essential. Reproduce code: --- url to patch (51 lines) http://user.et-cip.rub.de/korte/php-4.4.0-gmp-nextprime.patch Expected result: Use like: ?php $rand1 = gmp_random(10); echo Random: . gmp_strval($rand1) . br\n; $prime1 = gmp_nextprime($rand1); echo Next Prime: . gmp_strval($prime1) . br\n; } ? Actual result: -- Working fine in our installation - would like to have in the normal distribution as well :) -- Edit bug report at http://bugs.php.net/?id=33982edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33982r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33982r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33982r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33982r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33982r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33982r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33982r=needscript Try newer version: http://bugs.php.net/fix.php?id=33982r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33982r=support Expected behavior: http://bugs.php.net/fix.php?id=33982r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33982r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33982r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33982r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33982r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33982r=dst IIS Stability: http://bugs.php.net/fix.php?id=33982r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33982r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33982r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33982r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33982r=mysqlcfg
#31644 [Bgs-Opn]: Mimetype Functions are deprecated in favour of an unstable replacement
ID: 31644 Updated by: [EMAIL PROTECTED] -Summary: Mimetype Functions are deprecated in favour of an ustable replacement Reported By: peter at jingo dot com -Status: Bogus +Status: Open -Bug Type:Documentation problem +Bug Type:Unknown/Other Function PHP Version: Irrelevant New Comment: Don't mark it as bogus if it isn't. Previous Comments: [2005-02-04 11:35:37] [EMAIL PROTECTED] You are maybe right but it's not a documentation problem. [2005-01-21 19:19:12] peter at jingo dot com Description: The documentation for the Mimetype Functions says that it is deprecated and to use the FileInfo PECL extension which is not stable, experimental and has no documentation. The mimetype functions shouldn't be depreciated until a suitable replacement is available. -- Edit this bug report at http://bugs.php.net/?id=31644edit=1
#29454 [Fbk-Csd]: php_check_syntax second argument doesn't work in the right way
ID: 29454 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Unknown/Other Function Operating System: Linux PHP Version: 5CVS-2004-07-30 (dev) New Comment: Has been fixed in the meanwhile. Previous Comments: [2004-08-18 08:51:06] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Works fine here. [2004-07-30 07:26:45] [EMAIL PROTECTED] Description: The second argument of php_check_syntax is supposed to be passed by reference. However, you need to specify the reference where the function is called, like php_check_syntax($file, $error); resulting in Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of php_check_syntax(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. Reproduce code: --- php_check_syntax(test.php, $error); Expected result: errorstring in $error Actual result: -- Notice: Undefined variable: error -- Edit this bug report at http://bugs.php.net/?id=29454edit=1
#28704 [Bgs]: strange behaviour with references
ID: 28704
Updated by: [EMAIL PROTECTED]
Reported By: spy at spy dot zp dot ua
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: FreeBSD-4.x
PHP Version: 4.3.6
New Comment:
http://de.php.net/manual/en/language.references.whatdo.php
Note: If array with references is copied, its values are not
dereferenced. This is valid also for arrays passed by value to
functions.
Previous Comments:
[2004-06-30 15:17:32] spy at spy dot zp dot ua
Of course, I have checked manual, much more then twice.
Sorry, if you have no enough time to understand, that it is either real
bug, or a problem to be discussed and solved. And I have no time to dig
into source code to find out causes.
[2004-06-30 03:43:59] [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
See http://bugs.php.net/bug.php?id=20993edit=3
[2004-06-09 01:34:02] spy at spy dot zp dot ua
Description:
As shown in this example, the elements of $a become a references during
for cycle, although there are not have any aliases to their values.
If we make a copy ($b=$a) of an array, it becomes an array of
references too.
And only if we unset the copy ($b), engine founds that $a elements are
not really referenced by another vars.
The same result we can get with foreach($a), (because foreach works
with a copy of an array as noted in Bug #24486)
BTW, how can I make a really clean COPY of an array, including all of
it elements? And it should be useful to have a method to test if
variable have a reference(s).
Reproduce code:
---
$a = array(1, 2, 3);
for ($i = 0; $i count($a); $i++) {
$x = $a[$i];
}
$x=$nowhere;
print Dump 1 =; var_dump($a);
$b=$a;
$b['0']=6; $b['1']=7; $b['2']=8;
print Dump 2 =; var_dump($a);
unset($b);
print Dump 3 =; var_dump($a);
Expected result:
I don't know what to expect at all now =)
Before today I should expect all dumps like this:
Dump * =array(3) {
[0]=
int(1)
[1]=
int(2)
[2]=
int(3)
}
Actual result:
--
Dump 1 =array(3) {
[0]=
int(1)
[1]=
int(2)
[2]=
int(3)
}
Dump 2 =array(3) {
[0]=
int(6)
[1]=
int(7)
[2]=
int(8)
}
Dump 3 =array(3) {
[0]=
int(6)
[1]=
int(7)
[2]=
int(8)
}
--
Edit this bug report at http://bugs.php.net/?id=28704edit=1
#29686 [Opn]: Bug when using foreach on an array that has been referenced before
ID: 29686
Updated by: [EMAIL PROTECTED]
Reported By: swalk at prp dot physik dot tu-darmstadt dot de
Status: Open
Bug Type: Arrays related
Operating System: Linux
PHP Version: 5CVS-2004-08-15 (dev)
New Comment:
Please read properly before posting. And also read
http://www.php.net/foreach , especially the part with Note: Also note
that foreach operates on a copy of the specified array and not the array
itself.
And as was said, it only happens if you do $a = $a; before the foreach
clause. If you don't do it, you get the expected result.
Previous Comments:
[2004-08-15 14:55:40] jakub dot phpbug at horky dot net
I'm afraid that is caused just by the line
$a = foo;
which re-sets the $a variable to string, so it is no longer an array
and can't be enumerated by next loop...
[2004-08-15 12:37:33] swalk at prp dot physik dot tu-darmstadt dot de
Description:
When using foreach with an array that has been referenced before, it
behaves oddly if you re-set the variable inside the loop - it loses the
array it originally worked on. That doesn't happen if you leave the line
creating the reference out.
Reproduce code:
---
?php
$a = array(1,2,3);
$b = $a; // this line causes the bug
// $a = $a; does it too
foreach($a as $v) {
print $v\n;
$a = foo;
}
Expected result:
1
2
3
Actual result:
--
1
Warning: Invalid argument supplied for foreach() in /home/et/test.php
on line 4
--
Edit this bug report at http://bugs.php.net/?id=29686edit=1
#29686 [Bgs-Opn]: Bug when using foreach on an array that has been referenced before
ID: 29686
Updated by: [EMAIL PROTECTED]
Reported By: swalk at prp dot physik dot tu-darmstadt dot de
-Status: Bogus
+Status: Open
-Bug Type: Arrays related
+Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5CVS-2004-08-15 (dev)
New Comment:
Care to explain why doing $a = $a; before the loop should affect the
behaviour? In my (and some others whom i talked to) opinion that
behaviour is bogus. And if it does make sense, it should be reflected
in the documentation (where it isn't), because this caused someone an
error with a high WTF factor in an application.
Example:
foreach ($_SESSION['something'] as $foo) {
do_something;
$something = foo;
do_something_else;
}
Breaks on a server with register_globals on.
Previous Comments:
[2004-08-15 15:07:56] [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
.
[2004-08-15 15:05:48] [EMAIL PROTECTED]
Please read properly before posting. And also read
http://www.php.net/foreach , especially the part with Note: Also note
that foreach operates on a copy of the specified array and not the array
itself.
And as was said, it only happens if you do $a = $a; before the foreach
clause. If you don't do it, you get the expected result.
[2004-08-15 14:55:40] jakub dot phpbug at horky dot net
I'm afraid that is caused just by the line
$a = foo;
which re-sets the $a variable to string, so it is no longer an array
and can't be enumerated by next loop...
[2004-08-15 12:37:33] swalk at prp dot physik dot tu-darmstadt dot de
Description:
When using foreach with an array that has been referenced before, it
behaves oddly if you re-set the variable inside the loop - it loses the
array it originally worked on. That doesn't happen if you leave the line
creating the reference out.
Reproduce code:
---
?php
$a = array(1,2,3);
$b = $a; // this line causes the bug
// $a = $a; does it too
foreach($a as $v) {
print $v\n;
$a = foo;
}
Expected result:
1
2
3
Actual result:
--
1
Warning: Invalid argument supplied for foreach() in /home/et/test.php
on line 4
--
Edit this bug report at http://bugs.php.net/?id=29686edit=1
#29686 [Bgs-Opn]: Bug when using foreach on an array that has been referenced before
ID: 29686
Updated by: [EMAIL PROTECTED]
Reported By: swalk at prp dot physik dot tu-darmstadt dot de
-Status: Bogus
+Status: Open
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.*
New Comment:
I don't use register globals. But there are lots of servers which do.
1st, you're contradicting the Documentation, which clearly states that
the array should be copied: Note: Also note that foreach operates on
a copy of the specified array and not the array itself.
2nd, you didn't specify the difference between using a reference
variable and a normal variable.
If you do
foreach($array as $v) {
array_push($array, 0);
}
modifying the array, it doesn't affect the loop. By your reasoning, it
should?
Please don't bogus it again, because it is either a problem with the
documentation or with the implementation.
Previous Comments:
[2004-08-15 15:42:29] jakub dot phpbug at horky dot net
Sorry for mistyping the bug numbers: bug #28939 and bug #29687
[2004-08-15 15:40:53] jakub dot phpbug at horky dot net
To [EMAIL PROTECTED]:
especially the part with Note: Also note
that foreach operates on a copy of the specified
array and not the array itself.
Sorry, but that especially this paragraph is very obscure, because a
subsequent sentence states However, the internal pointer of the
original array is advanced with the processing of the array.
Furthermore, this is partially subject of recently opened bug #28939 or
#28939.
But there I really don't see any problem. Coincidental overwriting of
registered global is IMO really not bug but stupidity of the author :-)
[2004-08-15 15:27:49] [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
Don't use register globals. And don't use it for example because of
this problem.
Second, a reference variable and a normal variable do NOT result in
foreach copying the whole array. Instaed not accessing the data by ref
[foreach($ar as $data)] only results in copying the data. Therefor the
array is still ste same and if you change the array in the loop then
obviously you affect the loop.
[2004-08-15 15:20:05] [EMAIL PROTECTED]
Care to explain why doing $a = $a; before the loop should affect the
behaviour? In my (and some others whom i talked to) opinion that
behaviour is bogus. And if it does make sense, it should be reflected
in the documentation (where it isn't), because this caused someone an
error with a high WTF factor in an application.
Example:
foreach ($_SESSION['something'] as $foo) {
do_something;
$something = foo;
do_something_else;
}
Breaks on a server with register_globals on.
[2004-08-15 15:07:56] [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
.
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/29686
--
Edit this bug report at http://bugs.php.net/?id=29686edit=1
#29358 [Fbk-Opn]: PHP segfaults during shutdown because of custom stream wrapper
ID: 29358
Updated by: [EMAIL PROTECTED]
Reported By: swalk at prp dot physik dot tu-darmstadt dot de
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5CVS-2004-07-23 (dev)
New Comment:
Still the same.
[EMAIL PROTECTED]:~/downloads/sources/testing/php5-200407291830$ sapi/cli/php -r
'class a {} stream_register_wrapper(a,a);
php_check_syntax(http://localhost/test.txt;);'
Segmentation fault
Previous Comments:
[2004-07-29 14:02:30] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2004-07-23 21:46:35] swalk at prp dot physik dot tu-darmstadt dot de
Description:
If i have any custom wrapper registered, and try to include or
php_check_syntax() a file with a parse error in it, php segfaults
during shutdown.
Reproduce code:
---
$ php -r 'class a {} stream_register_wrapper(a,a);
php_check_syntax(http://localhost/test.txt;);'
Segmentation fault
test.txt contains just:
?php foo
Expected result:
No output and no segfault :)
Actual result:
--
(gdb) bt
#0 0x0019 in ?? ()
#1 0x08165371 in _php_stream_free (stream=0x82b7bc4,
close_options=11)
at /home/et/cvs.php.net/php-src/main/streams/streams.c:351
#2 0x081666b3 in stream_resource_regular_dtor (rsrc=0x82b78d4)
at /home/et/cvs.php.net/php-src/main/streams/streams.c:1343
#3 0x081916ae in list_entry_destructor (ptr=0x82b78d4)
at /home/et/cvs.php.net/php-src/Zend/zend_list.c:173
#4 0x08190279 in zend_hash_apply_deleter (ht=0x8211534, p=0x82b77bc)
at /home/et/cvs.php.net/php-src/Zend/zend_hash.c:574
#5 0x08190309 in zend_hash_graceful_reverse_destroy (ht=0x8211534)
at /home/et/cvs.php.net/php-src/Zend/zend_hash.c:640
#6 0x08180fb7 in shutdown_executor ()
at /home/et/cvs.php.net/php-src/Zend/zend_execute_API.c:282
#7 0x0818a25b in zend_deactivate () at
/home/et/cvs.php.net/php-src/Zend/zend.c:819
#8 0x08158981 in php_request_shutdown (dummy=0x0)
at /home/et/cvs.php.net/php-src/main/main.c:1212
#9 0x081b725f in main (argc=5, argv=0xb2e4)
at /home/et/cvs.php.net/php-src/sapi/cli/php_cli.c:1046
--
Edit this bug report at http://bugs.php.net/?id=29358edit=1
#27345 [Opn]: Status header with PHP CGI
ID: 27345
Updated by: [EMAIL PROTECTED]
Reported By: php_bugs at ecora dot de
Status: Open
-Bug Type:Documentation problem
+Bug Type:CGI related
PHP Version: Irrelevant
New Comment:
This is a bug, but not a documentation one.
Both PHP4 and PHP5 just send
HTTP/1.1 404\r\n...
when doing header('HTTP/1.0 404 Not found');
which isn't conforming to RFC 2616 (There has to be at least one space
after 404). That may cause Webservers to error out. This is
definitively a bug.
I don't think the reason-phrase should be discarded at all.
Previous Comments:
[2004-02-22 05:49:49] [EMAIL PROTECTED]
I couldn't reproduce this in PHP 5.
header(HTTP/1.0 404 Not Found); print Status: 404
and
header(Status: 404 Not Found); prints Status: 404 Not Found
Can anybody check this in PHP 4?
[2004-02-22 05:10:36] php_bugs at ecora dot de
Description:
Hi,
Documentation
header(HTTP/1.0 404 Not Found);
[...]
Note: In PHP 3, this only works when PHP is compiled as an Apache
module. You can achieve the same effect using the Status header.
header(Status: 404 Not Found);
/Documentation
IMHO this is not correct. Because the HTTP-status-header (also
Content-Type- and Location-Header) is always a server parsed header,
when PHP (PHP3, PHP4, PHP5 or also Perl or Python, ...) runs via CGI.
The official CGI Specification (see http://www.w3.org/CGI/):
http://hoohoo.ncsa.uiuc.edu/cgi/out.html
That means not only in PHP3 also in PHP4 or PHP5: When PHP runs via
CGI, then you have to write:
header(Status: 404 Not Found); instead of header(HTTP/1.0 404 Not
Found);
Reproduce code:
---
When i try to send a header(HTTP/1.0 404 Not Found); on my
installation (Apache 1.3.29 + PHP 4.2.3 CGI on Linux) then i receive a
500 internal server error
--
Edit this bug report at http://bugs.php.net/?id=27345edit=1
#27345 [Opn]: Status header with PHP CGI
ID: 27345
Updated by: [EMAIL PROTECTED]
Reported By: php_bugs at ecora dot de
Status: Open
Bug Type:CGI related
PHP Version: Irrelevant
New Comment:
Well, to be correct, PHP just sends Status: 404\r\n.
Previous Comments:
[2004-02-22 06:09:08] [EMAIL PROTECTED]
This is a bug, but not a documentation one.
Both PHP4 and PHP5 just send
HTTP/1.1 404\r\n...
when doing header('HTTP/1.0 404 Not found');
which isn't conforming to RFC 2616 (There has to be at least one space
after 404). That may cause Webservers to error out. This is
definitively a bug.
I don't think the reason-phrase should be discarded at all.
[2004-02-22 05:49:49] [EMAIL PROTECTED]
I couldn't reproduce this in PHP 5.
header(HTTP/1.0 404 Not Found); print Status: 404
and
header(Status: 404 Not Found); prints Status: 404 Not Found
Can anybody check this in PHP 4?
[2004-02-22 05:10:36] php_bugs at ecora dot de
Description:
Hi,
Documentation
header(HTTP/1.0 404 Not Found);
[...]
Note: In PHP 3, this only works when PHP is compiled as an Apache
module. You can achieve the same effect using the Status header.
header(Status: 404 Not Found);
/Documentation
IMHO this is not correct. Because the HTTP-status-header (also
Content-Type- and Location-Header) is always a server parsed header,
when PHP (PHP3, PHP4, PHP5 or also Perl or Python, ...) runs via CGI.
The official CGI Specification (see http://www.w3.org/CGI/):
http://hoohoo.ncsa.uiuc.edu/cgi/out.html
That means not only in PHP3 also in PHP4 or PHP5: When PHP runs via
CGI, then you have to write:
header(Status: 404 Not Found); instead of header(HTTP/1.0 404 Not
Found);
Reproduce code:
---
When i try to send a header(HTTP/1.0 404 Not Found); on my
installation (Apache 1.3.29 + PHP 4.2.3 CGI on Linux) then i receive a
500 internal server error
--
Edit this bug report at http://bugs.php.net/?id=27345edit=1
#27345 [Opn]: Status header with PHP CGI
ID: 27345
Updated by: [EMAIL PROTECTED]
Reported By: php_bugs at ecora dot de
Status: Open
Bug Type:CGI related
PHP Version: Irrelevant
New Comment:
Nope, that's simply not true.
It doesn't matter what you pass to header().
What matters is the output created by PHP, and if you use
header(HTTP/1.0 404 Foo Bar); PHP parses that and turns it into a
Status: line if you use CGI.
Previous Comments:
[2004-02-22 09:32:52] php_bugs at ecora dot de
I don't know. Maybe there is also a PHP Bug, but IMHO there is at least
a documentation bug. When you send a HTTP-Status-Header via the common
gateway interface to the http-server, then you have to write:
Status: ddd string
instead of
HTTP/1.1 ddd string
Please take a look at the CGI-Specification :
http://hoohoo.ncsa.uiuc.edu/cgi/out.html
PARSED HEADERS
The output of scripts begins with a small header. This header consists
of text lines, in the same format as an HTTP header, terminated by a
blank line (a line with only a linefeed or CR/LF).
[..]
Status
This is used to give the server an HTTP/1.0 status line to send to the
client. The format is nnn x, where nnn is the 3-digit status code,
and x is the reason string, such as Forbidden.
[2004-02-22 06:11:02] [EMAIL PROTECTED]
Well, to be correct, PHP just sends Status: 404\r\n.
[2004-02-22 06:09:08] [EMAIL PROTECTED]
This is a bug, but not a documentation one.
Both PHP4 and PHP5 just send
HTTP/1.1 404\r\n...
when doing header('HTTP/1.0 404 Not found');
which isn't conforming to RFC 2616 (There has to be at least one space
after 404). That may cause Webservers to error out. This is
definitively a bug.
I don't think the reason-phrase should be discarded at all.
[2004-02-22 05:49:49] [EMAIL PROTECTED]
I couldn't reproduce this in PHP 5.
header(HTTP/1.0 404 Not Found); print Status: 404
and
header(Status: 404 Not Found); prints Status: 404 Not Found
Can anybody check this in PHP 4?
[2004-02-22 05:10:36] php_bugs at ecora dot de
Description:
Hi,
Documentation
header(HTTP/1.0 404 Not Found);
[...]
Note: In PHP 3, this only works when PHP is compiled as an Apache
module. You can achieve the same effect using the Status header.
header(Status: 404 Not Found);
/Documentation
IMHO this is not correct. Because the HTTP-status-header (also
Content-Type- and Location-Header) is always a server parsed header,
when PHP (PHP3, PHP4, PHP5 or also Perl or Python, ...) runs via CGI.
The official CGI Specification (see http://www.w3.org/CGI/):
http://hoohoo.ncsa.uiuc.edu/cgi/out.html
That means not only in PHP3 also in PHP4 or PHP5: When PHP runs via
CGI, then you have to write:
header(Status: 404 Not Found); instead of header(HTTP/1.0 404 Not
Found);
Reproduce code:
---
When i try to send a header(HTTP/1.0 404 Not Found); on my
installation (Apache 1.3.29 + PHP 4.2.3 CGI on Linux) then i receive a
500 internal server error
--
Edit this bug report at http://bugs.php.net/?id=27345edit=1
#27345 [Bgs-Opn]: Status header with PHP CGI
ID: 27345
Updated by: [EMAIL PROTECTED]
Reported By: php_bugs at ecora dot de
-Status: Bogus
+Status: Open
Bug Type:CGI related
PHP Version: Irrelevant
New Comment:
There's no reason for the CGI sapi cutting of the reason-phrase when
creating the Status: line, is there?
The Status: header that it's outputting is invalid.
Previous Comments:
[2004-02-22 17:35:38] [EMAIL PROTECTED]
See cgi.rfc2616_headers php.ini directive.
[2004-02-22 15:41:39] [EMAIL PROTECTED]
Nope, that's simply not true.
It doesn't matter what you pass to header().
What matters is the output created by PHP, and if you use
header(HTTP/1.0 404 Foo Bar); PHP parses that and turns it into a
Status: line if you use CGI.
[2004-02-22 09:32:52] php_bugs at ecora dot de
I don't know. Maybe there is also a PHP Bug, but IMHO there is at least
a documentation bug. When you send a HTTP-Status-Header via the common
gateway interface to the http-server, then you have to write:
Status: ddd string
instead of
HTTP/1.1 ddd string
Please take a look at the CGI-Specification :
http://hoohoo.ncsa.uiuc.edu/cgi/out.html
PARSED HEADERS
The output of scripts begins with a small header. This header consists
of text lines, in the same format as an HTTP header, terminated by a
blank line (a line with only a linefeed or CR/LF).
[..]
Status
This is used to give the server an HTTP/1.0 status line to send to the
client. The format is nnn x, where nnn is the 3-digit status code,
and x is the reason string, such as Forbidden.
[2004-02-22 06:11:02] [EMAIL PROTECTED]
Well, to be correct, PHP just sends Status: 404\r\n.
[2004-02-22 06:09:08] [EMAIL PROTECTED]
This is a bug, but not a documentation one.
Both PHP4 and PHP5 just send
HTTP/1.1 404\r\n...
when doing header('HTTP/1.0 404 Not found');
which isn't conforming to RFC 2616 (There has to be at least one space
after 404). That may cause Webservers to error out. This is
definitively a bug.
I don't think the reason-phrase should be discarded at all.
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/27345
--
Edit this bug report at http://bugs.php.net/?id=27345edit=1
#25494 [Csd-Opn]: array_merge allowing false as argument (silent when non-array is passed)
ID: 25494 Updated by: [EMAIL PROTECTED] Reported By: enygma at phpdeveloper dot org -Status: Closed +Status: Open Bug Type: Arrays related Operating System: Any PHP Version: 4.3.2 New Comment: This behaviour IS documented for array_splice. This behaviour IS documented in the type juggling chapter of the PHP manual. Additionally, it's the standard way for PHP to handle arguments of the `wrong' type: It casts. You don't consider it a bug that floor(3.2) returns float(3), do you? But you consider it a bug that array_merge() casts to array if it doesn't get one? Major inconsistency there. Previous Comments: [2003-09-18 15:06:06] [EMAIL PROTECTED] It can't break BC if the behaviour was undocumented and hence undefined. So either document the behaviour or fix the bug. Anybody relying on undocumented 'features' should know they're at risk for having those behaviours changed. J [2003-09-18 06:45:48] [EMAIL PROTECTED] It's still inconsistent, and `will throw a warning and fail in 5 for non-array arguments' will break BC without a need for it. [2003-09-18 06:08:03] [EMAIL PROTECTED] Throwing an E_NOTICE error is not breaking anything. [2003-09-18 05:56:38] [EMAIL PROTECTED] This `fix' is inconsistent with array_splice, which allows you to add non-array arguments. (This is also documented.) Also, this `fix' breaks BC. Is this really needed? I'd rather have those functions convert non-array arguments into arrays and then perform their operations like array_splice() does. This has to be documented of course. [2003-09-11 13:57:55] [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. array_merge() throws E_NOTICEs now in 4.3.x and will throw a warning and fail in 5 for non-array arguments. J 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/25494 -- Edit this bug report at http://bugs.php.net/?id=25494edit=1
#25494 [Bgs]: array_merge allowing false as argument (silent when non-array is passed)
ID: 25494 Updated by: [EMAIL PROTECTED] Reported By: enygma at phpdeveloper dot org Status: Bogus Bug Type: Arrays related Operating System: Any PHP Version: 4.3.2 New Comment: Merging a single element into an array does make sense. *array*_merge merges arrays, not booleans, or ints, or strings. Then why str_repeat(10,10) repeats the int? Previous Comments: [2003-09-19 10:36:13] [EMAIL PROTECTED] This current behavior is correct. *array*_merge merges arrays, not booleans, or ints, or strings. Silently converting those to arrays makes no sense, and is quite confusing. Also, relying on an undocumented feature is not our problem, but the users'. [2003-09-19 08:25:32] [EMAIL PROTECTED] This behaviour IS documented for array_splice. This behaviour IS documented in the type juggling chapter of the PHP manual. Additionally, it's the standard way for PHP to handle arguments of the `wrong' type: It casts. You don't consider it a bug that floor(3.2) returns float(3), do you? But you consider it a bug that array_merge() casts to array if it doesn't get one? Major inconsistency there. [2003-09-18 15:06:06] [EMAIL PROTECTED] It can't break BC if the behaviour was undocumented and hence undefined. So either document the behaviour or fix the bug. Anybody relying on undocumented 'features' should know they're at risk for having those behaviours changed. J [2003-09-18 06:45:48] [EMAIL PROTECTED] It's still inconsistent, and `will throw a warning and fail in 5 for non-array arguments' will break BC without a need for it. [2003-09-18 06:08:03] [EMAIL PROTECTED] Throwing an E_NOTICE error is not breaking anything. 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/25494 -- Edit this bug report at http://bugs.php.net/?id=25494edit=1
#25494 [Csd-Opn]: array_merge allowing false as argument (silent when non-array is passed)
ID: 25494 Updated by: [EMAIL PROTECTED] Reported By: enygma at phpdeveloper dot org -Status: Closed +Status: Open Bug Type: Arrays related -Operating System: Red Hat Linux +Operating System: Any PHP Version: 4.3.2 New Comment: This `fix' is inconsistent with array_splice, which allows you to add non-array arguments. (This is also documented.) Also, this `fix' breaks BC. Is this really needed? I'd rather have those functions convert non-array arguments into arrays and then perform their operations like array_splice() does. This has to be documented of course. Previous Comments: [2003-09-11 13:57:55] [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. array_merge() throws E_NOTICEs now in 4.3.x and will throw a warning and fail in 5 for non-array arguments. J [2003-09-11 12:11:09] [EMAIL PROTECTED] Jay, it's an undocumented feature. If it is not documented and obscure it's developer's risk to use it. So, I think this is a bug and a check for the input parameter should be performed. A warning throwed in the same way as array_intersect() does will be the consistent way. Opening again :) [2003-09-11 11:50:39] enygma at phpdeveloper dot org it still seems silly to me that a string passed into an array function was taken without so much as a warning. even more strange that it was suddenly treated as an array and merged into the other valid array. maybe a warning would be enough to deter this in the future? [2003-09-11 11:42:26] [EMAIL PROTECTED] If you use var_dump() in place of print_r(), you'd see that it's not a mysterious value, it's 'false'. The boolean value is being converted to an array index in array_merge(). (Any value would produce similar results -- $array1=4; would produce an array value of $last_array[0]==4.) array_intersect() does a type check before it does anything, which is why the warning comes up. While it seems inconsistent, I can't see this being changed because it would affect BC (albeit BC on a somewhat obscure, undocumented feature). Somebody correct me here if I'm wrong. So I'm bogusing it for now. J [2003-09-11 11:42:19] [EMAIL PROTECTED] 1. Please use var_dump() instead of print_r() 2. The value in the merged array is (bool) false 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/25494 -- Edit this bug report at http://bugs.php.net/?id=25494edit=1
#25494 [Csd-Opn]: array_merge allowing false as argument (silent when non-array is passed)
ID: 25494 Updated by: [EMAIL PROTECTED] Reported By: enygma at phpdeveloper dot org -Status: Closed +Status: Open Bug Type: Arrays related Operating System: Any PHP Version: 4.3.2 New Comment: It's still inconsistent, and `will throw a warning and fail in 5 for non-array arguments' will break BC without a need for it. Previous Comments: [2003-09-18 06:08:03] [EMAIL PROTECTED] Throwing an E_NOTICE error is not breaking anything. [2003-09-18 05:56:38] [EMAIL PROTECTED] This `fix' is inconsistent with array_splice, which allows you to add non-array arguments. (This is also documented.) Also, this `fix' breaks BC. Is this really needed? I'd rather have those functions convert non-array arguments into arrays and then perform their operations like array_splice() does. This has to be documented of course. [2003-09-11 13:57:55] [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. array_merge() throws E_NOTICEs now in 4.3.x and will throw a warning and fail in 5 for non-array arguments. J [2003-09-11 12:11:09] [EMAIL PROTECTED] Jay, it's an undocumented feature. If it is not documented and obscure it's developer's risk to use it. So, I think this is a bug and a check for the input parameter should be performed. A warning throwed in the same way as array_intersect() does will be the consistent way. Opening again :) [2003-09-11 11:50:39] enygma at phpdeveloper dot org it still seems silly to me that a string passed into an array function was taken without so much as a warning. even more strange that it was suddenly treated as an array and merged into the other valid array. maybe a warning would be enough to deter this in the future? 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/25494 -- Edit this bug report at http://bugs.php.net/?id=25494edit=1
#24159 [Opn-Ver]: Php starts indexing from zero if lowest index is negative
ID: 24159 Updated by: [EMAIL PROTECTED] Reported By: rsen010 at ec dot auckland dot ac dot nz -Status: Open +Status: Verified -Bug Type: Documentation problem +Bug Type: Arrays related -Operating System: windos 2000 +Operating System: Any PHP Version: 4.3.2 New Comment: This behaviour was introduced in 4.3.0 - reclassifying as an array problem. I don't know if the behaviour or the documentation should be changed. Previous Comments: [2003-06-12 15:38:20] rsen010 at ec dot auckland dot ac dot nz Description: Hi, When I was going through Chapter 7.types in PHP manual I found something confusing regarding the following statement Having e.g. the highest index being -6 will result in -5 being the new key (under Syntax specifying with array()).What actually happens is it Php starts indexing from zero if lowest index is negative value unless there is no index of zero. But amazing thing is sometimes it omit some values unless. Just consider the following examples. Ex:1 $a = array(-3='February', 'March'); print_r($a); This will prints out the folloiwng Array ( [-3] = February [0] = March ) Ex:2 $a = array( 'January', '0'='a','b', 'c',-3='February', 'March'); print_r($a); This will prints out the folloiwng Array ( [0] = a [1] = b [2] = c [-3] = February [3] = March ) Please be kind to check this out if Im correct and reply me. Thanks Naleen Reproduce code: --- $a = array(-3='February', 'March'); print_r($a); $a = array( 'January', '0'='a','b', 'c',-3='February', 'March'); print_r($a); Expected result: Array (-3=February, [-2] = March ); Array ( [1]=January [0] = a [2] = b [3] = c [-3] = February [4] = March ) Actual result: -- Array ([-3] = February [0] = March ) Array ( [0] = a [1] = b [2] = c [-3] = February [3] = March ) -- Edit this bug report at http://bugs.php.net/?id=24159edit=1
#21611 [Opn]: Problem with version_compare() (Was: Problem with pear cli and release numbers)
ID: 21611
Updated by: [EMAIL PROTECTED]
-Summary: Problem with pear cli and release numbers
Reported By: jan at horde dot org
Status: Open
-Bug Type: PEAR related
+Bug Type: PHP options/info functions
Operating System: Any
PHP Version: 4CVS-2003-01-13 (stable)
Assigned To: gschlossnagle
New Comment:
reclassifying as PHP options/info functions
Previous Comments:
[2003-08-02 09:35:44] [EMAIL PROTECTED]
I'd go for B) and change it, since it's easy and the p suffix is quite
common... here's a patch that does it:
Index: versioning.c
===
RCS file: /repository/php-src/ext/standard/versioning.c,v
retrieving revision 1.15
diff -u -r1.15 versioning.c
--- versioning.c10 Jun 2003 20:03:39 - 1.15
+++ versioning.c2 Aug 2003 14:28:45 -
@@ -90,7 +90,7 @@
compare_special_version_forms(char *form1, char *form2)
{
int found1 = -1, found2 = -1;
- special_forms_t special_forms[9] = {
+ special_forms_t special_forms[10] = {
{dev, 0},
{alpha, 1},
{a, 1},
@@ -99,6 +99,7 @@
{RC, 3},
{#, 4},
{pl, 5},
+ {p, 5},
{NULL, 0},
};
special_forms_t *pp;
[2003-08-01 05:40:08] [EMAIL PROTECTED]
version_compare does handle suffixes. (see example below) However, p1
is not a valid suffix for this function. So, solutions would be imo:
A) use the pl suffix and document this
B) make version_compare handle pl and p equally
Example script:
?php
$version[] = 4.0.1pl2;
$version[] = 4.0.1pl1;
$version[] = 4.0.1b;
$version[] = 4.0.1a;
$version[] = 4.0.1p1;
$version[] = 4.0.1;
printf(%10s | %10s | %10s\n, Version 1, Version 2, New Vers.);
print str_repeat('-',36).\n;
for ($i = 0, $s = count($version); $i $s; $i++ ) {
for ($j = $i; $j $s; $j++) {
printf(%10s | %10s | ,$version[$i],$version[$j]);
$c = version_compare($version[$i], $version[$j]);
switch ($c) {
case -1:
$r = $version[$j];
break;
case 0:
$r = 'equal';
break;
case 1:
$r = $version[$i];
}
printf(%10s\n, $r);
}
}
?
Result:
Version 1 | Version 2 | New Vers.
4.0.1pl2 | 4.0.1pl2 | equal
4.0.1pl2 | 4.0.1pl1 | 4.0.1pl2
4.0.1pl2 | 4.0.1b | 4.0.1pl2
4.0.1pl2 | 4.0.1a | 4.0.1pl2
4.0.1pl2 |4.0.1p1 | 4.0.1pl2
4.0.1pl2 | 4.0.1 | 4.0.1pl2
4.0.1pl1 | 4.0.1pl1 | equal
4.0.1pl1 | 4.0.1b | 4.0.1pl1
4.0.1pl1 | 4.0.1a | 4.0.1pl1
4.0.1pl1 |4.0.1p1 | 4.0.1pl1
4.0.1pl1 | 4.0.1 | 4.0.1pl1
4.0.1b | 4.0.1b | equal
4.0.1b | 4.0.1a | 4.0.1b
4.0.1b |4.0.1p1 | 4.0.1b
4.0.1b | 4.0.1 | 4.0.1
4.0.1a | 4.0.1a | equal
4.0.1a |4.0.1p1 | 4.0.1a
4.0.1a | 4.0.1 | 4.0.1
4.0.1p1 |4.0.1p1 | equal
4.0.1p1 | 4.0.1 | 4.0.1
4.0.1 | 4.0.1 | equal
[2003-07-31 15:19:07] [EMAIL PROTECTED]
Um, PHP version 5.0.0b1 is a PHP version with a suffix. I'd call this
a valid bug, especially because this can be fixed by using
strnatcasecmp() instead of version_compare(). Perhaps this is a bug in
version_compare(), and should be noted as such?
Greg
[2003-07-31 14:50:16] [EMAIL PROTECTED]
Yes many developers have this problem because of lack of
documentation.
Opening back as a documentation problem (even if we don't have this
category for PEAR and btw we should have more categories for PEAR).
Can anyone write a little para on this?
[2003-07-31 14:16:24] [EMAIL PROTECTED]
this should be then at least noted in the PEAR developer
documenation... My package is not the first one with this problem
(and using p1 as suffix is pretty standard for software versions) so
that note is needed.
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/21611
--
Edit this bug report at http://bugs.php.net/?id=21611edit=1
#22661 [NEW]: mysql_list_tables selects database
From: lucifer at vengeance dot et dot tudelft dot nl
Operating system: PHP: WinXP MySQL: Win2k
PHP version: 4.2.3
PHP Bug Type: MySQL related
Bug description: mysql_list_tables selects database
the function mysql_list_tables changes the database subsequent queries
will run on; an example:
$link = mysql_connect( host, user, password );
mysql_select_db( db1, $link );
/* now db1 is selected */
print ** tables in selected database before mysql_list_tables **BR
$q = mysql_query( show tables );
while( $row = mysql_fetch_array( $q ) ) {
print $row[0].BR;
}
$tables = mysql_list_tables( db2 );
/* now db2 is selected */
print ** tables in selected database after mysql_list_tables **BR
$q = mysql_query( show tables );
while( $row = mysql_fetch_array( $q ) ) {
print $row[0].BR;
}
--
Edit bug report at http://bugs.php.net/?id=22661edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22661r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22661r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22661r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22661r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22661r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22661r=support
Expected behavior: http://bugs.php.net/fix.php?id=22661r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22661r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22661r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22661r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22661r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22661r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22661r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22661r=gnused
#22661 [Opn]: mysql_list_tables selects database
ID: 22661
User updated by: lucifer at vengeance dot et dot tudelft dot nl
Reported By: lucifer at vengeance dot et dot tudelft dot nl
Status: Open
Bug Type: MySQL related
Operating System: PHP: WinXP MySQL: Win2k
PHP Version: 4.2.3
New Comment:
sorry for the parsing errors in the example; i saw them too late :)
Previous Comments:
[2003-03-12 10:45:33] lucifer at vengeance dot et dot tudelft dot nl
the function mysql_list_tables changes the database subsequent
queries will run on; an example:
$link = mysql_connect( host, user, password );
mysql_select_db( db1, $link );
/* now db1 is selected */
print ** tables in selected database before mysql_list_tables **BR
$q = mysql_query( show tables );
while( $row = mysql_fetch_array( $q ) ) {
print $row[0].BR;
}
$tables = mysql_list_tables( db2 );
/* now db2 is selected */
print ** tables in selected database after mysql_list_tables **BR
$q = mysql_query( show tables );
while( $row = mysql_fetch_array( $q ) ) {
print $row[0].BR;
}
--
Edit this bug report at http://bugs.php.net/?id=22661edit=1
