#48177 [Opn->Bgs]: Cannot wrap eval'd code with HTML
ID: 48177
Updated by: matt...@php.net
Reported By: skds1433 at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Windows Vista
PHP Version: 5.2.9
New Comment:
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
eval() doesn't return anything but NULL unless a return statement is
used in the eval'd code (wouldn't work in this case with inline HTML
anyway, which gets echo'd immediately). You'd need to 1) echo "";
before the eval() call, 2) use eval('return "testing 123, a string, not
HTML...";'), or 3) use output buffering, etc.
Previous Comments:
[2009-05-07 10:22:38] skds1433 at hotmail dot com
Changed category, from 'Output Control'. Not really sure what this
applies to.
[2009-05-07 10:13:29] skds1433 at hotmail dot com
Description:
For debugging purposes of a template system, I am trying to wrap the
output of an eval inside pre HTML tags. Oddly, the tags are simply being
appended.
PHP version: 5.2.9-2
Apache: 2.2.11
Reproduce code:
---
testing1 "testing2 extended" "testing3 extended")0123456789
012345678901234567890123456789
testing4 testing5 ';
$buffer = eval("?>".$buffer);
echo "".$buffer."";
?>
Expected result:
testing 1 2 3, test test test test.
0123456789012345678901234567890123456789
012345678901234567890123456789
0123456789012345678901234567890123456789()0123456789
012345678901234567890123456789
Actual result:
--
testing 1 2 3, test test test test.
0123456789012345678901234567890123456789
012345678901234567890123456789
0123456789012345678901234567890123456789()0123456789
012345678901234567890123456789
--
Edit this bug report at http://bugs.php.net/?id=48177&edit=1
#48254 [Opn]: Inconsistent handling of huge numerical keys for array
ID: 48254
Updated by: matt...@php.net
Reported By: for-bugs at hnw dot jp
Status: Open
Bug Type: Arrays related
Operating System: any
PHP Version: 5.2.9
New Comment:
See Bug #45877.
This has been fixed in PHP 5.3. I didn't backport the change to 5.2
since it's been around forever and didn't know if the fix would be
wanted in 5.2 (primarily by who's in charge of it) at this point in its
lifecycle.
I'll leave this open for now to see if other devs have a comment...
Previous Comments:
[2009-05-13 03:47:05] for-bugs at hnw dot jp
Description:
There is inconsistency in dealing with huge numerical array key.
We know PHP normalizes array key with numerical string to integer if
possible. For instance, $a["1"] is equevalent to $a[1]. However, it is
not valid about PHP_INT_MAX and ~PHP_INT_MAX (2147483647 and -2147483648
in 32bit envirionment).
Reproduce code:
---
int(2)
}
Actual result:
--
array(2) {
[2147483647]=>
int(1)
["2147483647"]=>
int(2)
}
--
Edit this bug report at http://bugs.php.net/?id=48254&edit=1
#48254 [Asn->Csd]: Inconsistent handling of huge numerical keys for array
ID: 48254
Updated by: matt...@php.net
Reported By: for-bugs at hnw dot jp
-Status: Assigned
+Status: Closed
Bug Type: Arrays related
Operating System: *
-PHP Version: 5.2, 6CVS (2009-05-13)
+PHP Version: 5.2.9
Assigned To: mattwil
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Taken care of now!
I know, Jani, and I've merged other fixes. :-) Just thought this might
be considered, by others, more of a "feature change," since previous bug
reports had been dismissed. And Dmitry, nor anyone else, said anything
about including 5.2 when the change was made in HEAD/5.3 2 months
ago...
Nope, this has nothing to do with the other part missing from HEAD. ;-)
Even though I didn't personally commit this fix, it was done in HEAD as
well. (I've changed the reported version back to 5.2.9)
Previous Comments:
[2009-05-13 18:40:51] j...@php.net
Matt, bug fixes should go into PHP_5_2. And I guess this is the same
patch needing MFB to HEAD too? :)
[2009-05-13 14:25:42] matt...@php.net
See Bug #45877.
This has been fixed in PHP 5.3. I didn't backport the change to 5.2
since it's been around forever and didn't know if the fix would be
wanted in 5.2 (primarily by who's in charge of it) at this point in its
lifecycle.
I'll leave this open for now to see if other devs have a comment...
[2009-05-13 03:47:05] for-bugs at hnw dot jp
Description:
There is inconsistency in dealing with huge numerical array key.
We know PHP normalizes array key with numerical string to integer if
possible. For instance, $a["1"] is equevalent to $a[1]. However, it is
not valid about PHP_INT_MAX and ~PHP_INT_MAX (2147483647 and -2147483648
in 32bit envirionment).
Reproduce code:
---
int(2)
}
Actual result:
--
array(2) {
[2147483647]=>
int(1)
["2147483647"]=>
int(2)
}
--
Edit this bug report at http://bugs.php.net/?id=48254&edit=1
#45877 [Csd]: Array key '2147483647' left as string
ID: 45877
Updated by: matt...@php.net
Reported By: henryptung at gmail dot com
Status: Closed
Bug Type: Arrays related
Operating System: CentOS 4
PHP Version: 5.2.6
Assigned To: mattwil
New Comment:
Also fixed in 5.2 now. See Bug #48254.
Previous Comments:
[2009-03-18 01:12:17] matt...@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.
Just fixed in 5.3 for now.
[2009-03-17 18:45:16] matt...@php.net
I had also noticed this issue awhile back. Finally created a simple fix
so it works consistently and as expected, and will apply it soon,
hopefully.
http://realplain.com/php/array_key_limit.diff
http://realplain.com/php/array_key_limit_5_3.diff
[2008-08-21 07:18:04] johan...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
use a 64bit machine for big integers
[2008-08-21 03:04:14] henryptung at gmail dot com
Description:
I believe '2147483647' (= 2^31 - 1) should be the standard
representation of a valid integer, but using the string form as an array
key stores the key as a string, not an integer. The integer key
2147483647 can be used separately to refer to a different value, and
both are stored. See repro code below:
Note: this bug is admittedly duplicate of bug #13407, but the bug still
exists, and I fail to understand why the original bug was marked bogus.
Thanks for your time.
Reproduce code:
---
$v = array('2147483647' => 'b', '2147483646' => 'c', 2147483647 =>
'd');
var_dump($v);
Expected result:
array(2) {
[2147483647]=>
string(1) "d"
[2147483646]=>
string(1) "c"
}
Actual result:
--
array(3) {
["2147483647"]=>
string(1) "b"
[2147483646]=>
string(1) "c"
[2147483647]=>
string(1) "d"
}
--
Edit this bug report at http://bugs.php.net/?id=45877&edit=1
#48446 [Opn]: Tokenizer reports two T_INLINE_HTML at tags starting with s
ID: 48446 Updated by: matt...@php.net Reported By: shawn at shawnbiddle dot com Status: Open Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.2.9 New Comment: Yeah, that's just how the tokenizer/scanner has always worked. It stops at ", etc.) from being taken as inline HTML. The regular expressions in the scanner can't "look ahead" to make sure what follows is NOT a PHP opening tag, and it would be more complicated, if it's even possible (been awhile since I looked), to do extra checking in the code after scanning additional input... The good news, however, is that a new scanner is used for PHP 5.3, and as of a few weeks ago (5.3.0 RC2), it now works as you'd expect. All continuous HTML is kept as one token. :-) Previous Comments: [2009-06-01 16:48:12] shawn at shawnbiddle dot com Description: If token_get_all is run on a script that contains both PHP and HTML it will split T_INLINE_HTML tokens up any time it runs across an html tag starting with s. My example uses span but as I said, it's any tag starting with s. Reproduce code: --- HelloHello!')); ?> Expected result: Array ( [0] => Array ( [0] => 367 [1] => 1 ) [1] => Array ( [0] => 316 [1] => echo [2] => 1 ) [2] => Array ( [0] => 370 [1] => [2] => 1 ) [3] => Array ( [0] => 315 [1] => "Hello World!" [2] => 1 ) [4] => ; [5] => Array ( [0] => 370 [1] => [2] => 1 ) [6] => Array ( [0] => 369 [1] => ?> [2] => 1 ) [7] => Array ( [0] => 311 [1] => HelloHello! [2] => 1 ) [8] => Array ( [0] => 367 [1] => 1 ) [9] => Array ( [0] => 316 [1] => echo [2] => 1 ) [10] => Array ( [0] => 370 [1] => [2] => 1 ) [11] => Array ( [0] => 315 [1] => "Goodbye, World!" [2] => 1 ) [12] => ; [13] => Array ( [0] => 370 [1] => [2] => 1 ) [14] => Array ( [0] => 369 [1] => ?> [2] => 1 ) ) Actual result: -- Array ( [0] => Array ( [0] => 367 [1] => 1 ) [1] => Array ( [0] => 316 [1] => echo [2] => 1 ) [2] => Array ( [0] => 370 [1] => [2] => 1 ) [3] => Array ( [0] => 315 [1] => "Hello World!" [2] => 1 ) [4] => ; [5] => Array ( [0] => 370 [1] => [2] => 1 ) [6] => Array ( [0] => 369 [1] => ?> [2] => 1 ) [7] => Array ( [0] => 311 [1] => Hello [2] => 1 ) [8] => Array ( [0] => 311 [1] => 1 ) [9] => Array ( [0] => 311 [1] => pan class="test">Hello! [2] => 1 ) [10] => Array ( [0] => 367 [1] => 1 ) [11] => Array ( [0] => 316 [1] => echo [2] => 1 ) [12] => Array ( [0] => 370 [1] => [2] => 1 ) [13] => Array ( [0] => 315 [1] => "Goodbye, World!" [2] => 1 ) [14] => ; [15] => Array ( [0] => 370 [1] => [2] => 1 ) [16] => Array ( [0] => 369 [1] => ?> [2] => 1 ) ) -- Edit this bug report at http://bugs.php.net/?id=48446&edit=1
#47836 [Ver->Csd]: array operator [] inconsistency when the array has PHP_INT_MAX index value
ID: 47836
Updated by: matt...@php.net
-Summary: array operator [] inconsistency when the array has
PHP_MAX_INT index value
Reported By: for-bugs at hnw dot jp
-Status: Verified
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.2.9
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2009-03-30 11:00:31] matt...@php.net
Untested, but it seems like this would give the expected result. In
zend_hash.c:_zend_hash_index_update_or_next_insert(), change the check
from
if ((long)h >= (long)ht->nNextFreeElement) {
ht->nNextFreeElement = h + 1;
}
to
if (h >= ht->nNextFreeElement && h < LONG_MAX) {
ht->nNextFreeElement = h + 1;
}
[2009-03-30 07:40:48] for-bugs at hnw dot jp
Description:
The behavior of operator [] to the array is sometimes strange or hard
to describe the specification. For instance, the array which has two
index, 2147483647 and -2147483648 on 32bit environment gets strange
results. See below example:
Reproduce code:
---
int(2)
[2147483647]=>
int(1)
}
array(3) {
[2147483647]=>
int(1)
[-2147483648]=>
int(2)
[-2147483647]=>
int(3)
}
--
Edit this bug report at http://bugs.php.net/?id=47836&edit=1
#48093 [Bgs]: Generated index is reset due to integer overflow
ID: 48093 Updated by: matt...@php.net Reported By: Marcel dot Glacki at stud dot fh-swf dot de Status: Bogus Bug Type: Arrays related Operating System: * PHP Version: 5.2.9 New Comment: Your initial report is technically correct, as far as what's happening internally, and the second example shows it -- the initial example would too if this line is commented/removed: $arr[1] = 'one'; // New index: 2 Otherwise, this is a duplicate of Bug #47836, which is now fixed. The initial code will still give the same warning (I'm sure you expect that though), but for a different reason internally. :-) Previous Comments: [2009-04-28 14:03:13] Marcel dot Glacki at stud dot fh-swf dot de Hi, well, I checked the manual (even in other languages). But if I missed something essential let me know. What I wanted to point out is, that the manual says integers are converted to float if an integer overflow is encountered. (See: http://www.php.net/manual/en/language.types.integer.php at section "Integer overflow") Furthermore the manual says about using arrays if when no index is given the array generates itself an index to use. (See: http://www.php.net/manual/en/language.types.array.php at section "Creating/modifying with square bracket syntax") It says: "As mentioned above, if no key is specified, the maximum of the existing integer indices is taken, and the new key will be that maximum value plus 1." So what happens when this maximum value is already MAX_INT ? It then is not converted to float and if so, it would then be truncated to integer ... and then the integer overflow comes across. Again, the manual says "the MAXIMUM of the existing integer indices ... is taken" and that's just not true for the code I provided in the first post and the one down below. Here's another code sample to show: Which prints: Array ( [0] => some [2147483647] => values [-2147483648] => another [-2147483647] => value ) Regards, Marcel [2009-04-28 07:55:29] sni...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2009-04-27 23:02:39] Marcel dot Glacki at stud dot fh-swf dot de Description: The generated index normally has the highest integer value regarding all integers it has encountered as indexes before. (And is automatically increased by +1) It is possible to reset this index (the internal pointer) not only by the functions intended to do so (like reset()) but also by increasing it above integers' max value (integer overflow). Reproduce code: --- -- Edit this bug report at http://bugs.php.net/?id=48093&edit=1
#49991 [Opn]: json_decode integer truncation on 32-bit machines
ID: 49991
Updated by: matt...@php.net
Reported By: warren at guy dot net dot au
Status: Open
Bug Type: JSON related
Operating System: FreeBSD 6.3
PHP Version: 5.2.11
New Comment:
Are you cross-compiling for 32-bit, on a 64-bit system...?
Previous Comments:
[2009-10-25 13:33:59] warren at guy dot net dot au
Description:
json_decode truncates numbers greater than 32 bit int 2147483647 on 32
bit system
Reproduce code:
---
Expected result:
object(stdClass)#1 (4) {
["test_id_small_int"]=>
int(12345)
["test_id_maxint"]=>
int(2147483647)
["test_id_maxint_plus_two"]=>
float(2147483649)
["test_id_huge_int"]=>
float(800)
}
or even strings instead of floats would work for me.
Actual result:
--
object(stdClass)#1 (4) {
["test_id_small_int"]=>
int(12345)
["test_id_maxint"]=>
int(2147483647)
["test_id_maxint_plus_two"]=>
int(2147483647)
["test_id_huge_int"]=>
int(2147483647)
}
--
Edit this bug report at http://bugs.php.net/?id=49991&edit=1
#45953 [Opn->Bgs]: Sign-Bit Manipulating is buggy
ID: 45953 Updated by: [EMAIL PROTECTED] Reported By: ben at umingo dot de -Status: Open +Status: Bogus Bug Type: Output Control Operating System: Windows XP 32Bit PHP Version: 5.2.6 New Comment: 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 What's happening is that when the script is parsed and compiled, 0x81234567 actually becomes a float/double type since, as you mention, it's too big for 32-bit signed range and the intended behavior is to keep it positive (as it would be on platforms with 64-bit longs) and not restrict it to integer type only. The bitwise operators like | only operate on integers, and it converts a float/double to int first, which results in "overflow" to a negative number that you're seeing. Typecasting to (int) will also force the overflow (same internal conversion used by bitwise operators), and give the result you expect (on 32-bit platform anyway). Example: "; echo (0x81234567 | 0x81234567); //result is negative echo ""; echo (0x81234567 );//result is positive echo "without sign bit "; //WORKS echo (0x71234567 | 0x71234567); echo ""; echo (0x71234567 ); ?> Expected result: with sign bit -2128394905 -2128394905 without sign bit 1898136935 1898136935 Actual result: -- with sign bit -2128394905 2166572391 without sign bit 1898136935 1898136935 -- Edit this bug report at http://bugs.php.net/?id=45953&edit=1
#45957 [Opn->Bgs]: I accidentally a whole namespace
ID: 45957 Updated by: [EMAIL PROTECTED] Reported By: nobody at example dot org -Status: Open +Status: Bogus Bug Type:Unknown/Other Function PHP Version: 5.2.6 New Comment: 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. Oops? Have to be more careful next time! Not possible since namespaces are first included in 5.3, of course. :-P Previous Comments: [2008-08-30 20:02:15] nobody at example dot org Description: I accidentally a whole namespace, is that bad? -- Edit this bug report at http://bugs.php.net/?id=45957&edit=1
#45970 [Bgs]: Weird rounding behaviour
ID: 45970
Updated by: [EMAIL PROTECTED]
Reported By: jan dot vernieuwe at webline dot be
Status: Bogus
Bug Type: Math related
Operating System: FreeBSD
PHP Version: 5.2.6
New Comment:
Oh, Scott just beat me. :-) Well here's a bit extra I wrote:
The result of subtraction ($myVal) is stored as a value slightly less
than 57.645, due to floating-point precision, which is why it rounds to
57.64 in the 3rd var_dump(). The 2nd and 4th var_dump() are using the
same value, with closer float representation to what you want (57.645).
By that I mean, in the 4th, as a string, $myVal is first converted to a
string, exactly as the first example does to print the var_dump()
output, then that "57.645" string is converted to float, exactly as the
numeric version in the 2nd example is when the script is parsed/compiled
(so they have the same internal float representation, and will behave
the same).
Previous Comments:
[2008-09-02 09:28:07] [EMAIL PROTECTED]
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about "floats" and what IEEE
754 is, read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
Thank you for your interest in PHP.
[2008-09-02 09:08:36] jan dot vernieuwe at webline dot be
Description:
Rounding a calculated float gives bad results, rounding it as a string
works as intended.
Reproduce code:
---
";
$total = 332.145;
$substract = 274.5;
$myVal = $total-$substract;
var_dump($myVal);
var_dump(round(57.645,2));
var_dump(round($myVal,2));
var_dump(round("$myVal",2));
echo "";
?>
Expected result:
float(57.645)
float(57.65)
float(57.65)
float(57.65)
Actual result:
--
float(57.645)
float(57.65)
float(57.64)
float(57.65)
--
Edit this bug report at http://bugs.php.net/?id=45970&edit=1
#45974 [Opn->Bgs]: parse_ini_file strange work with some char combination
ID: 45974 Updated by: [EMAIL PROTECTED] Reported By: mete0 at gtn dot ru -Status: Open +Status: Bogus Bug Type: *Directory/Filesystem functions Operating System: OpenBSD current PHP Version: 5.2.6 New Comment: 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. You must be viewing this print_r() output in a browser? It's interpreting the < as the beginning of an HTML tag (the ending ")" of "Array ( ... )" was lost too). View the page source and you'll see the correct output there. Reopen if that's not the case. :-) Previous Comments: [2008-09-02 16:07:47] mete0 at gtn dot ru Small typo in reproduce code, file name must be `config.ini` not `config.in` [2008-09-02 16:01:50] mete0 at gtn dot ru Description: Function `parse_ini_file()` work strange with this char combination `!work fine too" three = " Expected result: Array ( [one] => work fine [two] => >!work fine too [three] => -- Edit this bug report at http://bugs.php.net/?id=45974&edit=1
#45978 [Opn->Bgs]: round() errors.
ID: 45978 Updated by: [EMAIL PROTECTED] Reported By: firealwaysworks at gmail dot com -Status: Open +Status: Bogus Bug Type: Math related Operating System: Linux PHP Version: 5.2.6 New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is, read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. The result of 21.33*1.015 is stored as slightly less than 21.64995 (21.6499497 on my Windows system), different than when you write the literal static value. The result of 21.33*1.015 when printing it (happens differently than round() function, so results may vary) or rounding 5-14 decimal places, those extra internal 9s are "rolled over." Previous Comments: [2008-09-03 02:09:39] firealwaysworks at gmail dot com Description: In this example the multiplication of two floats yields a number with 5 significant figures. The round() function incorrectly handles this number only when it is working with the answer to a mathematical operation. It is important to note that the round() function is working properly for static values. I found this because I am writing financial software in PHP. I have absolutely no doubt that this bug would cause our company to loose money. Reproduce code: --- print 21.33*1.015.""; print round(21.33*1.015,2).""; print round(21.33*1.015,4).""; print round(21.64995,4); Expected result: 21.64995 21.65 21.65 21.65 Actual result: -- 21.64995 21.65 21.6499 21.65 -- Edit this bug report at http://bugs.php.net/?id=45978&edit=1
#46708 [Opn->Csd]: until => unless in php.ini* files
ID: 46708 Updated by: [EMAIL PROTECTED] Reported By: RQuadling at GMail dot com -Status: Open +Status: Closed Bug Type: *Configuration Issues Operating System: Windows XP Pro SP3 PHP Version: 6CVS-2008-11-28 (CVS) New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-11-28 13:32:32] RQuadling at GMail dot com Description: Related to bug #46675, the ini files use the "until" rather than "unless". Patch below Reproduce code: --- Index: php.ini-dist === RCS file: /repository/php-src/php.ini-dist,v retrieving revision 1.281 diff -u -r1.281 php.ini-dist --- php.ini-dist13 Nov 2008 19:05:36 - 1.281 +++ php.ini-dist28 Nov 2008 13:27:51 - @@ -297,7 +297,7 @@ log_errors_max_len = 1024 ; Do not log repeated messages. Repeated errors must occur in same file on same -; line until ignore_repeated_source is set true. +; line unless ignore_repeated_source is set true. ignore_repeated_errors = Off ; Ignore source of message when ignoring repeated messages. When this setting Index: php.ini-recommended === RCS file: /repository/php-src/php.ini-recommended,v retrieving revision 1.231 diff -u -r1.231 php.ini-recommended --- php.ini-recommended 13 Nov 2008 19:05:36 - 1.231 +++ php.ini-recommended 28 Nov 2008 13:27:50 - @@ -336,7 +336,7 @@ log_errors_max_len = 1024 ; Do not log repeated messages. Repeated errors must occur in same file on same -; line until ignore_repeated_source is set true. +; line unless ignore_repeated_source is set true. ignore_repeated_errors = Off ; Ignore source of message when ignoring repeated messages. When this setting -- Edit this bug report at http://bugs.php.net/?id=46708&edit=1
#46701 [Ver]: hexadecimal index keys converted wrong in 32bit systems
ID: 46701 Updated by: [EMAIL PROTECTED] Reported By: testuzer at hotmail dot com Status: Verified Bug Type: Arrays related Operating System: Linux - ubuntu PHP Version: 5CVS, 6CVS (2008-11-28) New Comment: Is this really only happening with array indexes...? Either way, the bug title isn't accurate. If it's only with array indexes, it shouldn't be hexadecimal-related, but would be coming from the simple (long) cast of any double value (from "long values in the key") in zend_hash_*, resulting in "undefined behavior." But, are those values even correct before the array part gets processed? e.g. does var_dump(0xcc5c4600) give 3428599296? If not, then it's obviously not array-specific. :-) Hmm, I was just going to say, see Bug #45068 for the possible cause (and http://news.php.net/php.internals/40199), but I just noticed that you marked that Bogus Jani? Cross-compiling isn't supported? Well, I guess you're not doing that then when reproducing this... How about you, bug reporter? Previous Comments: [2008-11-28 12:37:40] [EMAIL PROTECTED] Same result with 32bit linux, this is with 64bit: # php t.php Array ( [3428599296] => 1 [3459455488] => 1 [3459616768] => 1 ) [2008-11-27 21:04:17] testuzer at hotmail dot com Description: Creating associative array with long values in the key fails under linux builds but work under windows. Reproduce code: --- $test_array = array( 0xcc5c4600 => 1, 0xce331a00 => 1, 0xce359000 => 1, ); print_r( $test_array ); Expected result: Array ( [-866368000] => 1 [-835511808] => 1 [-835350528] => 1 ) Actual result: -- Array ( [-2147483648] => 1 ) -- Edit this bug report at http://bugs.php.net/?id=46701&edit=1
#46730 [Opn->Bgs]: json_decode and 32Bit Maschines
ID: 46730
Updated by: [EMAIL PROTECTED]
Reported By: info at marcel-schlesinger dot de
-Status: Open
+Status: Bogus
Bug Type: JSON related
Operating System: ALL
PHP Version: 5.2.6
New Comment:
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
Can't reproduce -- should be fixed since 5.2.4... Feel free to reopen
if you're actually using 5.2.6 and seeing this. :-)
Previous Comments:
[2008-12-02 13:01:36] info at marcel-schlesinger dot de
Updated category
[2008-12-02 12:53:32] info at marcel-schlesinger dot de
Description:
Using json_decode with numbers higher then 2147483647 on a 32Bit
maschine is still wrong! E.g. 5095334700020 has to be converted into a
float (a string would be also okay), but not into an integer!
Reproduce code:
---
Expected result:
object(stdClass)#1 (1) {
["number"]=>
float(5095334700020)
}
it could also be:
object(stdClass)#1 (1) {
["number"]=>
string(13) "5095334700020"
}
Actual result:
--
object(stdClass)#1 (1) {
["number"]=>
int(2147483647)
}
--
Edit this bug report at http://bugs.php.net/?id=46730&edit=1
#46783 [Opn->Bgs]: magic quotes not working
ID: 46783 Updated by: [EMAIL PROTECTED] Reported By: php at 2600 dot sk -Status: Open +Status: Bogus Bug Type: PHP options/info functions Operating System: Linux PHP Version: 5.2.7 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Duplicate of Bug #46759 Previous Comments: [2008-12-06 13:06:22] php at 2600 dot sk Description: I have just upgraded to php 5.2.7 and found that even when magic_quotes are On in php.ini and phpinfo() reports magic_quotes_gpc to be On, magic quotes do not work. Since deprecating and removal of magic quotes is announced from PHP 6, I consider this is a bug rather than a feature. Also, since get_magic_quotes_gpc() reports 1, it confuses scripts which handle inputs differently if magic quotes are on. -- Edit this bug report at http://bugs.php.net/?id=46783&edit=1
#46782 [Opn->Ver]: fastcgi.c parse error
ID: 46782 Updated by: [EMAIL PROTECTED] Reported By: whatloveis at hanmail dot net -Status: Open +Status: Verified Bug Type: Compile Failure Operating System: Linux PHP Version: 5.2.7 New Comment: Caused by changes for Bug #45522 Previous Comments: [2008-12-06 12:46:40] whatloveis at hanmail dot net Description: When I compile with FastCGI support, it gives a parse error. I think lines 226-236 in `sapi/cgi/fastcgi.c' should be placed in a block. Reproduce code: --- './configure' \ --disable-spl \ --disable-pdo \ --disable-xmlreader \ --disable-xmlwriter \ --disable-hash \ --without-sqlite \ --with-mysql=/usr/local/mysql \ --enable-mbstring \ --with-zlib \ --with-gd \ --with-freetype-dir \ --enable-fastcgi make Actual result: -- sapi/cgi/fastcgi.c: In function `fcgi_init': sapi/cgi/fastcgi.c:226: parse error before `sa' sapi/cgi/fastcgi.c:231: `sa' undeclared (first use in this function) sapi/cgi/fastcgi.c:231: (Each undeclared identifier is reported only once sapi/cgi/fastcgi.c:231: for each function it appears in.) sapi/cgi/fastcgi.c:231: `len' undeclared (first use in this function) -- Edit this bug report at http://bugs.php.net/?id=46782&edit=1
#46782 [Ver->Csd]: fastcgi.c parse error
ID: 46782 Updated by: [EMAIL PROTECTED] Reported By: whatloveis at hanmail dot net -Status: Verified +Status: Closed Bug Type: Compile Failure Operating System: Linux PHP Version: 5.2.7 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-12-06 15:06:27] [EMAIL PROTECTED] Caused by changes for Bug #45522 [2008-12-06 12:46:40] whatloveis at hanmail dot net Description: When I compile with FastCGI support, it gives a parse error. I think lines 226-236 in `sapi/cgi/fastcgi.c' should be placed in a block. Reproduce code: --- './configure' \ --disable-spl \ --disable-pdo \ --disable-xmlreader \ --disable-xmlwriter \ --disable-hash \ --without-sqlite \ --with-mysql=/usr/local/mysql \ --enable-mbstring \ --with-zlib \ --with-gd \ --with-freetype-dir \ --enable-fastcgi make Actual result: -- sapi/cgi/fastcgi.c: In function `fcgi_init': sapi/cgi/fastcgi.c:226: parse error before `sa' sapi/cgi/fastcgi.c:231: `sa' undeclared (first use in this function) sapi/cgi/fastcgi.c:231: (Each undeclared identifier is reported only once sapi/cgi/fastcgi.c:231: for each function it appears in.) sapi/cgi/fastcgi.c:231: `len' undeclared (first use in this function) -- Edit this bug report at http://bugs.php.net/?id=46782&edit=1
#47208 [Opn->Bgs]: Converting Float/Double to Integer bug.
ID: 47208
Updated by: matt...@php.net
Reported By: superdude at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: Math related
Operating System: win32/64 possibly others.
PHP Version: 5.2.8
New Comment:
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about "floats" and what IEEE
754 is, read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
Thank you for your interest in PHP.
1.003 is stored as slightly less than that (close as possible), which
can be seen when you show enough digits:
printf('%.20f', 1.003);
Gives 1.00289164 for me...
Previous Comments:
[2009-01-24 13:44:22] superdude at hotmail dot com
Description:
When multiplying a float/double that the has value of 1.003, converting
it to a integer, will always return the expected value, minus 1.
Reproduce code:
---
\n";
echo (int)($x*1)."\n";
echo (int)($x*10)."\n";
?>
Expected result:
1003
10030
100300
Actual result:
--
1002
10029
100299
--
Edit this bug report at http://bugs.php.net/?id=47208&edit=1
#47320 [Opn]: $php_errormsg out of scope in functions
ID: 47320
Updated by: matt...@php.net
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.3.0beta1
New Comment:
Caused, and missed, by Dmitry's lazy EG(active_symbol_table)
initialization? http://news.php.net/php.cvs/49754
Previous Comments:
[2009-02-05 23:48:06] danielc at analysisandsolutions dot com
Compared to 5.2.6.
[2009-02-05 23:45:07] j...@php.net
Compared to what version?
[2009-02-05 23:12:59] danielc at analysisandsolutions dot com
Description:
The scope of $php_errormsg has changed in 5.3. It is no longer
available inside functions.
Perhaps this is intentional, perhaps not. If it is intentional, I
encourage the decision be changed to improve compatibility between
versions.
If it won't be changed, we need to update the 5.3 upgrade guide at
http://wiki.php.net/doc/scratchpad/upgrade/53.
Reproduce code:
---
if (!...@substr('no 2nd parameter')) {
echo '$php_errormsg in global: ' . $php_errormsg . "\n";
}
function foo() {
if (!...@substr('no 2nd parameter')) {
echo '$php_errormsg in function: ' . $php_errormsg . "\n";
echo '$GLOBALS[php_errormsg] in function: ' .
$GLOBALS['php_errormsg'] . "\n";
}
}
foo();
Expected result:
$php_errormsg in global: substr() expects at least 2 parameters, 1
given
$php_errormsg in function: substr() expects at least 2 parameters, 1
given
$GLOBALS[php_errormsg] in function: substr() expects at least 2
parameters, 1 given
Actual result:
--
$php_errormsg in global: substr() expects at least 2 parameters, 1
given
Notice: Undefined variable: php_errormsg in
D:\webroot\ideasphp\Atest.html on line 10
$php_errormsg in function:
$GLOBALS[php_errormsg] in function: substr() expects at least 2
parameters, 1 given
--
Edit this bug report at http://bugs.php.net/?id=47320&edit=1
#47422 [Opn->Csd]: modulus operator returns incorrect results on 64 bit linux
ID: 47422
Updated by: matt...@php.net
Reported By: d_kelsey at uk dot ibm dot com
-Status: Open
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: Linux 64Bit
PHP Version: 5.2CVS-2009-02-17 (CVS)
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Thanks. Actually, just -1 needs to be checked there anyway, since only
when doing LONG_MIN % -1 (in PHP, "(-PHP_INT_MAX - 1) % -1;") would
there be a crash/error (which that's there to catch of course).
Previous Comments:
[2009-02-17 12:36:14] d_kelsey at uk dot ibm dot com
Description:
on a 64bit system the following
var_dump(1%4294967295);
should return 1, but returns 0.
The problem is in the
ZEND_API int mod_function(...) in zend_operators.c
A call is made to abs which expects a 32bit int and returns a 32bit
int, but 4294967295 is > 32 bits in size so the abs call returns an
incorrect value.
A proposed fix is to change the line
"if (abs(op2->value.lval) == 1) {"
to
"if (op2->value.lval == 1 || op2->value.lval == -1) {"
--
Edit this bug report at http://bugs.php.net/?id=47422&edit=1
#47574 [Opn->Bgs]: date() function works incorrect :-(
ID: 47574
Updated by: matt...@php.net
Reported By: privatevideo at list dot ru
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Windows
PHP Version: 5.2.9
New Comment:
We are happy to tell you that you just discovered Daylight Savings
Time. For more information see:
http://webexhibits.org/daylightsaving/b.html
Instead of using mktime/date consider using gmmktime and gmdate which
do
not suffer from DST.
Previous Comments:
[2009-03-05 16:57:39] privatevideo at list dot ru
Description:
date() function works incorrect :-(
Reproduce code:
---
# check line 179-180, it should add a minute every step
for ($i=0,$d=1224964800;$d<=1225051200;$d+=60,++$i)
echo "$i -> ".date('Y-m-d H:i:s',$d);
Expected result:
179 -> 2008-10-26 02:59:00
180 -> 2008-10-26 03:00:00
181 -> 2008-10-26 03:01:00
182 -> 2008-10-26 03:02:00
Actual result:
--
179 -> 2008-10-26 02:59:00
180 -> 2008-10-26 02:00:00
181 -> 2008-10-26 02:01:00
182 -> 2008-10-26 02:02:00
--
Edit this bug report at http://bugs.php.net/?id=47574&edit=1
#47657 [Bgs]: str_replace() should not call replace-functions when needle missing
ID: 47657
Updated by: matt...@php.net
Reported By: h dot reindl at thelounge dot net
Status: Bogus
Bug Type:Performance problem
PHP Version: 5.2.9
New Comment:
str_replace() is not "calling the replacement function." Your f1() and
f2() functions are called BEFORE str_replace() is run. Same in any
language, so there's certainly nothing str_replace() can do about it.
Once called, str_replace() doesn't do anything unnecessary when the
needle is missing. In other words, it's doing the same work as strpos(),
with the exception that it's also making a copy of the input string to
return, which can't be avoided either -- although you may be able to
measure the small amount of overhead (it's propotional to the input
length).
Previous Comments:
[2009-03-14 18:03:17] h dot reindl at thelounge dot net
And you think it is best practice every possible optimzing
that is suggestet by users throw against a wall?
Sorry but for me it seems since a long time that
php-developers are not interested in any help
and thinking about making things better from
the community
[2009-03-14 17:53:07] j...@php.net
str_replace() does not accept functions as the parameters like you
expect it to so there is no bug here either.
[2009-03-14 17:41:10] h dot reindl at thelounge dot net
Description:
If you use str_replace and the needle is not in the string there should
be no call to the replacement-function.
This can produce much overhead if the function is complex
At the moment you must manually check if you call the replace with
strpos - I think in many cases this will not happen and there is running
much overhead-code without any need in existing applications
Even if you know the problem it needs ugly php-code for get best
performance - If the php-core makes this check all exististing
applications can get better performance
Reproduce code:
---
';
}
function f2()
{
echo 'F2';
}
?>
Expected result:
Only f1() should be called
Actual result:
--
f1() AND f2() are called
--
Edit this bug report at http://bugs.php.net/?id=47657&edit=1
#45877 [Bgs->Asn]: Array key '2147483647' left as string
ID: 45877
Updated by: matt...@php.net
Reported By: henryptung at gmail dot com
-Status: Bogus
+Status: Assigned
Bug Type: Arrays related
Operating System: CentOS 4
PHP Version: 5.2.6
-Assigned To:
+Assigned To: mattwil
New Comment:
I had also noticed this issue awhile back. Finally created a simple fix
so it works consistently and as expected, and will apply it soon,
hopefully.
http://realplain.com/php/array_key_limit.diff
http://realplain.com/php/array_key_limit_5_3.diff
Previous Comments:
[2008-08-21 07:18:04] johan...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
use a 64bit machine for big integers
[2008-08-21 03:04:14] henryptung at gmail dot com
Description:
I believe '2147483647' (= 2^31 - 1) should be the standard
representation of a valid integer, but using the string form as an array
key stores the key as a string, not an integer. The integer key
2147483647 can be used separately to refer to a different value, and
both are stored. See repro code below:
Note: this bug is admittedly duplicate of bug #13407, but the bug still
exists, and I fail to understand why the original bug was marked bogus.
Thanks for your time.
Reproduce code:
---
$v = array('2147483647' => 'b', '2147483646' => 'c', 2147483647 =>
'd');
var_dump($v);
Expected result:
array(2) {
[2147483647]=>
string(1) "d"
[2147483646]=>
string(1) "c"
}
Actual result:
--
array(3) {
["2147483647"]=>
string(1) "b"
[2147483646]=>
string(1) "c"
[2147483647]=>
string(1) "d"
}
--
Edit this bug report at http://bugs.php.net/?id=45877&edit=1
#46882 [Asn->Csd]: Serialize / Unserialize misbehaviour under OS with different bit numbers
ID: 46882 Updated by: matt...@php.net -Summary: Serialize / Unserialize missbehaviour under OS with different bit numbers Reported By: max at phoenixweb dot it -Status: Assigned +Status: Closed Bug Type: Feature/Change Request Operating System: Centos 5.2 x86 64bit PHP Version: 5.2.8 Assigned To: mattwil New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-12-17 09:19:04] bj...@php.net There is nothing wrong with passing serialize()d strings between systems. Reclassifying as a bug a again. [2008-12-16 18:25:17] matt...@php.net I'd agree that it's a bug... And I'm surprised *I* didn't catch this one back when I was looking into other number-related stuff. :-) Patches for all 3 branches: http://realplain.com/php/bug46882.diff http://realplain.com/php/bug46882_5_3.diff http://realplain.com/php/bug46882_5_2.diff Commit? [2008-12-16 18:13:12] max at phoenixweb dot it WDDX is the best solutions to speak across different programming languages. But we are talking about 2 system serving PHP (not one PHP and another JAVA)! That should speak using PHP serialization of PHP objects. PHP is compatible with differents PHP server by using WDDX but cannot communicate with others PHP server by using its native way to serialize (this seems to me a little bit silly). But i won't ask for a personal solution just for my problem, consider the bug from another point of view: what about an upgrade of the current system to a system that run more than 4Gb of RAM. Should I trash all the data of my Sql stored as a SERIALIZED object I think this is silly. By the way i'm fixing this by forcing casting floats for every int on the 64bit before serialize. [2008-12-16 17:57:07] j...@php.net serialize() is not meant for passing data between systems. There are other methods for that. (wddx for example) [2008-12-16 15:26:18] max at phoenixweb dot it But this is a problem. Serialize is needed to store PHP object as a string. Is this correct? There are a lot of possibility of needed an object as a string, like complex data storage, and pass data from a server to another server. If the data is not unserializable from a different server, it's completely useless. When i'll upgrade my server to 12Gb of RAM (needing a 64bit OS), i'll have to trash all the data stored with SERIALIZE on my MySqls? I don't think that the correct way is just to add a comment to the current documentation. I think this should be consider a bug, cause SERIALIZE / UNSERIALIZE is used to storage data and pass it across servers, so must be compliant with the problems of differents OS system behaviours. 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/46882 -- Edit this bug report at http://bugs.php.net/?id=46882&edit=1
#45877 [Asn->Csd]: Array key '2147483647' left as string
ID: 45877
Updated by: matt...@php.net
Reported By: henryptung at gmail dot com
-Status: Assigned
+Status: Closed
Bug Type: Arrays related
Operating System: CentOS 4
PHP Version: 5.2.6
Assigned To: mattwil
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Just fixed in 5.3 for now.
Previous Comments:
[2009-03-17 18:45:16] matt...@php.net
I had also noticed this issue awhile back. Finally created a simple fix
so it works consistently and as expected, and will apply it soon,
hopefully.
http://realplain.com/php/array_key_limit.diff
http://realplain.com/php/array_key_limit_5_3.diff
[2008-08-21 07:18:04] johan...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
use a 64bit machine for big integers
[2008-08-21 03:04:14] henryptung at gmail dot com
Description:
I believe '2147483647' (= 2^31 - 1) should be the standard
representation of a valid integer, but using the string form as an array
key stores the key as a string, not an integer. The integer key
2147483647 can be used separately to refer to a different value, and
both are stored. See repro code below:
Note: this bug is admittedly duplicate of bug #13407, but the bug still
exists, and I fail to understand why the original bug was marked bogus.
Thanks for your time.
Reproduce code:
---
$v = array('2147483647' => 'b', '2147483646' => 'c', 2147483647 =>
'd');
var_dump($v);
Expected result:
array(2) {
[2147483647]=>
string(1) "d"
[2147483646]=>
string(1) "c"
}
Actual result:
--
array(3) {
["2147483647"]=>
string(1) "b"
[2147483646]=>
string(1) "c"
[2147483647]=>
string(1) "d"
}
--
Edit this bug report at http://bugs.php.net/?id=45877&edit=1
#47774 [Opn->Bgs]: Integer Overflow
ID: 47774 Updated by: matt...@php.net Reported By: vivekanandan8 at yahoo dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Debian PHP Version: 5.2CVS-2009-03-25 (snap) New Comment: This is the expected behavior. Happens because it's not parsed as a single negative number, but a positive number (and 2147483648 needs to be a float) that is then negated afterwards. So it's treated more like -(2147483648). Hope that helps explain what's going on. :-) Previous Comments: [2009-03-25 14:28:33] vivekanandan8 at yahoo dot com Description: Generally when integer number exceed(overflows), it is converted to float,But for the number -2147483648 the Integer can hold, but converted to float. Reproduce code: --- Expected result: int(-2147483648) int(-2147483648) Actual result: -- int(-2147483648) float(-2147483648) -- Edit this bug report at http://bugs.php.net/?id=47774&edit=1
#47763 [Opn->Bgs]: proc_get_status->wrong PID
ID: 47763
Updated by: matt...@php.net
Reported By: ies_clan at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: Filesystem function related
Operating System: Windows XP SP3
PHP Version: 5.2.9
New Comment:
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
That's the expected behavior because cmd.exe has been used to launch
notepad. To get the result you're expecting, use the bypass_shell option
of proc_open()'s 4th parameter (http://php.net/proc_open):
$process = proc_open($cmd, $descriptorspec, $pipes,
array('bypass_shell' => TRUE));
Previous Comments:
[2009-03-24 15:44:01] ies_clan at hotmail dot com
Description:
The function proc_get_status returns a wrong PID
Reproduce code:
---
array('pipe', 'r' ), 1 => array('pipe',
'w' ), 2 => array('pipe', 'w' ) );
$process = proc_open($cmd, $descriptorspec, $pipes);
$status = proc_get_status( $process );
echo 'PID = ', $status['pid'], "\n";
passthru( 'tasklist /fi "imagename eq notepad.exe"');
echo "\n\n";
passthru( 'tasklist /fi "pid eq ' . $status['pid'] . '"' );
echo "\n\n";
proc_terminate($process);
?>
Expected result:
PID = 2408
Abbildname PID Sitzungsname Sitz.-Nr.
Speichernutzung
= = ==
===
notepad.exe2408 Console 0
2.560 K
Abbildname PID Sitzungsname Sitz.-Nr.
Speichernutzung
= = ==
===
cmd.exe2336 Console 0
2.560 K
Actual result:
--
PID = 2336
Abbildname PID Sitzungsname Sitz.-Nr.
Speichernutzung
= = ==
===
notepad.exe2408 Console 0
2.560 K
Abbildname PID Sitzungsname Sitz.-Nr.
Speichernutzung
= = ==
===
cmd.exe2336 Console 0
2.560 K
--
Edit this bug report at http://bugs.php.net/?id=47763&edit=1
#47836 [Opn]: array operator [] has inconsistency when the array has PHP_MAX_INT index value.
ID: 47836
Updated by: matt...@php.net
Reported By: for-bugs at hnw dot jp
Status: Open
Bug Type: Arrays related
Operating System: *
PHP Version: 5.2.9
New Comment:
Untested, but it seems like this would give the expected result. In
zend_hash.c:_zend_hash_index_update_or_next_insert(), change the check
from
if ((long)h >= (long)ht->nNextFreeElement) {
ht->nNextFreeElement = h + 1;
}
to
if (h >= ht->nNextFreeElement && h < LONG_MAX) {
ht->nNextFreeElement = h + 1;
}
Previous Comments:
[2009-03-30 07:40:48] for-bugs at hnw dot jp
Description:
The behavior of operator [] to the array is sometimes strange or hard
to describe the specification. For instance, the array which has two
index, 2147483647 and -2147483648 on 32bit environment gets strange
results. See below example:
Reproduce code:
---
int(2)
[2147483647]=>
int(1)
}
array(3) {
[2147483647]=>
int(1)
[-2147483648]=>
int(2)
[-2147483647]=>
int(3)
}
--
Edit this bug report at http://bugs.php.net/?id=47836&edit=1
#47546 [Csd->Bgs]: Default value for limit parameter in explode is 0, not -1
ID: 47546 Updated by: matt...@php.net Reported By: jordi dot salvat at localbilinglimited dot com -Status: Closed +Status: Bogus Bug Type: Strings related Operating System: Irrelevant PHP Version: 5.2.9 Assigned To: kalle New Comment: Change reverted, as the behavior was correct. It's the documentation that's wrong. See Bug #47560 and Bug #47727. The default value for limit (3rd parameter) is just "unlimited," or the length of the input string, or PHP_INT_MAX, etc. Previous Comments: [2009-03-03 11:51:05] ka...@php.net This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Fixed in PHP 5.2.10 [2009-03-02 17:25:26] jordi dot salvat at localbilinglimited dot com Description: http://es.php.net/explode declares that the default value for the 3rd parameter of the explode function is -1. The function, however, behaves differently when -1 is passed explicitly. Reproduce code: --- php <<'__END__' __END__ Expected result: >From the documentation, I would expect to see the same result twice. Actual result: -- Array ( [0] => one [1] => two [2] => three [3] => four ) Array ( [0] => one [1] => two [2] => three ) -- Edit this bug report at http://bugs.php.net/?id=47546&edit=1
#47560 [Asn->Csd]: explode()'s limit parameter odd behaviour
ID: 47560 Updated by: matt...@php.net Reported By: RQuadling at GMail dot com -Status: Assigned +Status: Closed Bug Type: Strings related Operating System: * PHP Version: 5.3CVS-2009-03-04 (snap) -Assigned To: kalle +Assigned To: mattwil New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Yeah, change for Bug #47546 was reverted. It is a documentation problem. See Bug #47727. Previous Comments: [2009-03-05 01:26:29] fel...@php.net Hi Kalle, This issue looks like documentation problem. I guess that your commit to #47546 must be reverted. [2009-03-04 12:37:37] RQuadling at GMail dot com Description: With regard to #47546, the behaviour of no $limit supplied and $limit supplied as the default now match, but the output is wrong. I've run the following code for V5.2.8, V5.2.10-dev and V5.3.0beta2- dev (the devs are the latest win32 snapshots). Here is a summary ... V5.2.8 No limit - 4 entries Limit of -4 - No entries Limit of -3 - 1 entry Limit of -2 - 2 entries Limit of -1 - 4 entries *** Should be 3 entries Limit of 0 - 1 entry Limit of 1 - 1 entry Limit of 2 - 2 entries Limit of 3 - 3 entries Limit of 4 - 4 entries *** Matches No Limit 5.2.10-dev and 5.3.0beta2-dev No limit - 4 entries Limit of -4 - No entries Limit of -3 - 1 entry Limit of -2 - 2 entries Limit of -1 - 4 entries *** Should be 3 entries but does match No Limit Limit of 0 - 1 entry Limit of 1 - 1 entry Limit of 2 - 2 entries Limit of 3 - 3 entries Limit of 4 - 4 entries *** Matches No Limit It would seem that the idea of limit has a static value default is inappropriate. If anything the default for limit is the number of elements in no limiting takes place. Also a limit of -1 should be returning 3 elements and not 4. Richard. Reproduce code: --- http://bugs.php.net/?id=47560&edit=1
#47938 [Csd]: PHP 5.3.0 RC1 VC9 IIs Windows XP asks for MSVCR90.DLL
ID: 47938 Updated by: matt...@php.net Reported By: gert at yawar dot nl Status: Closed Bug Type: Dynamic loading Operating System: XP PHP Version: 5.3.0RC1 New Comment: Pierre, I had also noticed this with RC1 (CLI on XP SP3), but thought maybe I had something wrong with the 2008 runtime installation... However, a snapshot from before RC1 runs fine, as do the current ones. Are the "official" releases built differently than the snaps? Also, not sure it's related, but when I tried that pre-RC1 snap on Windows 2000 (with 2008 runtime installed, of course), it gave an error (not this one about "MSVCR90.DLL" though). Or are the VC9 releases not supposed to work on Win2k? The VC9 notes don't say that anywhere... Previous Comments: [2009-04-09 17:34:58] gert at yawar dot nl .exe from CVS snapshot runs OK [2009-04-09 17:07:18] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-04-09 16:44:19] gert at yawar dot nl Description: PHP 5.3.0 RC1 VC9 (ts) Windows XP IIS van't load module; php.exe asks for MSVCR90.DLL, although the 2008 c runtime redistribution is installed on this machine. When msvcr90.dll is added to the directory, a new complaint shows that the runtime is not called in appropriate manner. Probably during linking of php exe and dll, it was done without taking care of manifests. Are there other possibilities? -- Edit this bug report at http://bugs.php.net/?id=47938&edit=1
#47963 [Fbk]: PHP does not load - getaddrinfo doesn't exist
ID: 47963 Updated by: matt...@php.net Reported By: cranderson at att dot net Status: Feedback Bug Type: *Configuration Issues Operating System: Windows 2000 PHP Version: 5.3.0RC1 New Comment: Yes, confirmed. I knew it worked with XP SP3, and since I can't get to that 2000 system now, I just installed the 2008 runtime on an old 2000 laptop (same service pack and all) and tried the latest 5.3 snap. The OP's error is the one I'm seeing. Previous Comments: [2009-04-14 09:55:01] paj...@php.net I do not have a windows 2000 to test (fetching one now). Can you confirm that it works with XP but not with 2000 (if you can :) please? [2009-04-14 09:48:46] matt...@php.net Yeah, I'm pretty sure this is the error I was getting in 2000 that I mentioned in Bug #47938. (Wondered whether the VC9 releases are supposed to work on 2000, though the VC9 notes don't say otherwise.) SP4 (+ Update Rollup 1) for me if you're asking about 2000's service pack. [2009-04-13 21:43:30] paj...@php.net Does it work on XP or do you see this error only on windows 2000? If yes, which service pack do you use? [2009-04-13 21:37:38] cranderson at att dot net Description: Windows Binary: php-5.3-win32-VC9-x86-latest.zip (Win2000 Pro/Win2000 Server - VC9 libraries installed) Windows error message: "The procedure entry point getaddrinfo could not be located in the dynamic link library ws2_32.dll." Microsoft Link: http://msdn.microsoft.com/en-us/library/ms738520(VS.85).aspx In brief: The getaddrinfo function was added to the Ws2_32.dll on Windows XP and later. To execute an application that uses this function on earlier versions of Windows, then you need to include the Ws2tcpip.h and Wspiapi.h files. getaddrinfo support on versions of Windows earlier than Windows XP is limited to handling IPv4 name resolution. The GetAddrInfoW function cannot be used on versions of Windows earlier than Windows XP with SP2. Thanks, Carl Reproduce code: --- // cli sapi php -v Expected result: PHP version. Actual result: -- Windows error message: "The procedure entry point getaddrinfo could not be located in the dynamic link library ws2_32.dll." -- Edit this bug report at http://bugs.php.net/?id=47963&edit=1
#47963 [Fbk]: PHP does not load - getaddrinfo doesn't exist
ID: 47963 Updated by: matt...@php.net Reported By: cranderson at att dot net Status: Feedback Bug Type: *Configuration Issues Operating System: Windows 2000 PHP Version: 5.3.0RC1 New Comment: I haven't used that tool before, so not exactly sure what I'm supposed to check, sorry. :-/ But anyway, selecting WS2_32.DLL under PHP.EXE > PHP5TS.DLL, the *addrinfo functions aren't in the bottom pane on 2000, and in the upper pane, freeaddrinfo/getaddrinfo are red instead of green on XP. Additionally, on 2000, the log area says "Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module." Is that even close to anything you wanted to know...? A little lost in this area, but if you give me instructions, hopefully I can help. :-) (I'll be away for a bit now...) Previous Comments: [2009-04-14 10:23:51] paj...@php.net Ok, I can't get a windows 2000 easily. But reading again the error, it has nothing to do with the headers (we use them correctly or it will not even compile) but with the fact that your ws2 dll does not expose or contain getaddrinfo. Can you send verify it using depends.exe please? [2009-04-14 10:12:22] matt...@php.net Yes, confirmed. I knew it worked with XP SP3, and since I can't get to that 2000 system now, I just installed the 2008 runtime on an old 2000 laptop (same service pack and all) and tried the latest 5.3 snap. The OP's error is the one I'm seeing. [2009-04-14 09:55:01] paj...@php.net I do not have a windows 2000 to test (fetching one now). Can you confirm that it works with XP but not with 2000 (if you can :) please? [2009-04-14 09:48:46] matt...@php.net Yeah, I'm pretty sure this is the error I was getting in 2000 that I mentioned in Bug #47938. (Wondered whether the VC9 releases are supposed to work on 2000, though the VC9 notes don't say otherwise.) SP4 (+ Update Rollup 1) for me if you're asking about 2000's service pack. [2009-04-13 21:43:30] paj...@php.net Does it work on XP or do you see this error only on windows 2000? If yes, which service pack do you use? 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/47963 -- Edit this bug report at http://bugs.php.net/?id=47963&edit=1
#47963 [Fbk]: PHP does not load - getaddrinfo doesn't exist
ID: 47963 Updated by: matt...@php.net Reported By: cranderson at att dot net Status: Feedback Bug Type: *Configuration Issues Operating System: Windows 2000 PHP Version: 5.3.0RC1 New Comment: Yeah, I'm pretty sure this is the error I was getting in 2000 that I mentioned in Bug #47938. (Wondered whether the VC9 releases are supposed to work on 2000, though the VC9 notes don't say otherwise.) SP4 (+ Update Rollup 1) for me if you're asking about 2000's service pack. Previous Comments: [2009-04-13 21:43:30] paj...@php.net Does it work on XP or do you see this error only on windows 2000? If yes, which service pack do you use? [2009-04-13 21:37:38] cranderson at att dot net Description: Windows Binary: php-5.3-win32-VC9-x86-latest.zip (Win2000 Pro/Win2000 Server - VC9 libraries installed) Windows error message: "The procedure entry point getaddrinfo could not be located in the dynamic link library ws2_32.dll." Microsoft Link: http://msdn.microsoft.com/en-us/library/ms738520(VS.85).aspx In brief: The getaddrinfo function was added to the Ws2_32.dll on Windows XP and later. To execute an application that uses this function on earlier versions of Windows, then you need to include the Ws2tcpip.h and Wspiapi.h files. getaddrinfo support on versions of Windows earlier than Windows XP is limited to handling IPv4 name resolution. The GetAddrInfoW function cannot be used on versions of Windows earlier than Windows XP with SP2. Thanks, Carl Reproduce code: --- // cli sapi php -v Expected result: PHP version. Actual result: -- Windows error message: "The procedure entry point getaddrinfo could not be located in the dynamic link library ws2_32.dll." -- Edit this bug report at http://bugs.php.net/?id=47963&edit=1
#47854 [Ver]: explode() misbehaves with very large negative limit
ID: 47854
Updated by: matt...@php.net
Reported By: disas at mail dot ru
Status: Verified
Bug Type: Strings related
Operating System: *
PHP Version: 5.*, 6CVS (2009-04-01)
New Comment:
What's happening with -1e9 is that it's small enough to fit in the
range of an integer (which explode()'s limit parameter expects). (Other
larger numbers that aren't in the integer range may or may not behave as
expected -- if there's integer overflow/"wraparound", with -3e9 for
example, negative may become positive, or vice versa, giving different
behavior than the sign of limit would suggest.)
However, when you give a much larger number like -1e99 and it gets cast
to an integer, it actually just becomes 0 which explains the behavior
you're seeing.
Additional info that the bug reporter can ignore if they want:
That explanation applies to PHP 5.2 and prior. But in 5.3 as of right
now, on *most* platforms (except Win64), *most* numbers out of integer
range (except between 2^31 and 2^32-1 on 32-bit platforms) have a "hard
limit" applied that keeps them at the negative/positive integer limit,
so no matter how large of a number you pass to explode(), even infinity,
it ends up being the integer limit (with same sign). Like I said, this
varies by platform, but that's the general behavior in 5.3 right now.
Overall, 5.3's conversion of large floats is currently inconsistent,
flawed, and changes prior behavior that's been around for years, which
is why I'm trying to get it sorted out. Now in cases like this, with
function parameters like a "limit," the new behavior makes sense (which
only happens in *most* cases, thanks to platform inconsistencies).
But wait, it gets better: Don't pass the parameter as a number, but as
a string, e.g. '-1e99', and you'll probably get a different result
still! Again, depending on platform -- absolute difference between
platforms and/or relative difference compared to a non-string version.
What a mess... And this applies to basically every function in 5.3 that
takes an integer parameter. My proposed changes take care of these
things and allow functions, like explode(), to use a new integer
conversion specifier, where desired, to limit a parameter to the range
of an integer *consistently*. Functions that aren't updated would simply
behave like 5.2 and prior.
Previous Comments:
[2009-04-01 11:00:26] j...@php.net
Very strange results with HEAD/PHP_5_3 too:
# build/php_6/sapi/cli/php -n -dmemory_limit=2G -r
'var_dump(explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ",
-1e99));'
Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried
to allocate 18446744073383068122 bytes) in Command line code on line
1
# build/php_5_3/sapi/cli/php -n -dmemory_limit=2G -r
'var_dump(explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ",
-1e99));'
Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried
to allocate 3792765909 bytes) in Command line code on line 1
# build/php_5_2/sapi/cli/php -n -dmemory_limit=2G -r
'var_dump(explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ",
-1e99));'
array(1) {
[0]=>
string(43) " 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 "
}
[2009-03-31 19:15:47] disas at mail dot ru
Description:
Bug on result where negative or positive number of limit is very high.
Reproduce code:
---
#Code:
var_export(
explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ", -1e99)
);
#Result:
array (
0 => ' 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ',
);
#Code:
var_export(
explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ", -1e9)
);
#Result:
array (
)
Expected result:
array (
0 => ' 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ',
);
Actual result:
--
I think that in both cases the result should be:
array(
)
--
Edit this bug report at http://bugs.php.net/?id=47854&edit=1
#47854 [Ver]: explode() misbehaves with very large negative limit
ID: 47854
Updated by: matt...@php.net
Reported By: disas at mail dot ru
Status: Verified
Bug Type: Strings related
Operating System: *
PHP Version: 5.*, 6CVS (2009-04-01)
New Comment:
Jani, as you can tell from my explanation, -1e99 becomes 0 with 5.2,
but LONG_MIN with 5.3/6. In the explode() function, there is/was a
int/long mismatch, so overflow issues on 64-bit, causing an unexpected
value of "limit" in php_explode_negative_limit() and, I'm guessing, an
invalid read of "positions" there.
I fixed the long/int mismatch in 5.3/6 a couple weeks ago, so I assume
the strange results are gone? BTW, since 5.2 isn't using long where
needed, you should be able to break it (on 64-bit) by passing
-PHP_INT_MAX - 1 instead of -1e99.
Previous Comments:
[2009-04-15 15:02:08] matt...@php.net
What's happening with -1e9 is that it's small enough to fit in the
range of an integer (which explode()'s limit parameter expects). (Other
larger numbers that aren't in the integer range may or may not behave as
expected -- if there's integer overflow/"wraparound", with -3e9 for
example, negative may become positive, or vice versa, giving different
behavior than the sign of limit would suggest.)
However, when you give a much larger number like -1e99 and it gets cast
to an integer, it actually just becomes 0 which explains the behavior
you're seeing.
Additional info that the bug reporter can ignore if they want:
That explanation applies to PHP 5.2 and prior. But in 5.3 as of right
now, on *most* platforms (except Win64), *most* numbers out of integer
range (except between 2^31 and 2^32-1 on 32-bit platforms) have a "hard
limit" applied that keeps them at the negative/positive integer limit,
so no matter how large of a number you pass to explode(), even infinity,
it ends up being the integer limit (with same sign). Like I said, this
varies by platform, but that's the general behavior in 5.3 right now.
Overall, 5.3's conversion of large floats is currently inconsistent,
flawed, and changes prior behavior that's been around for years, which
is why I'm trying to get it sorted out. Now in cases like this, with
function parameters like a "limit," the new behavior makes sense (which
only happens in *most* cases, thanks to platform inconsistencies).
But wait, it gets better: Don't pass the parameter as a number, but as
a string, e.g. '-1e99', and you'll probably get a different result
still! Again, depending on platform -- absolute difference between
platforms and/or relative difference compared to a non-string version.
What a mess... And this applies to basically every function in 5.3 that
takes an integer parameter. My proposed changes take care of these
things and allow functions, like explode(), to use a new integer
conversion specifier, where desired, to limit a parameter to the range
of an integer *consistently*. Functions that aren't updated would simply
behave like 5.2 and prior.
[2009-04-01 11:00:26] j...@php.net
Very strange results with HEAD/PHP_5_3 too:
# build/php_6/sapi/cli/php -n -dmemory_limit=2G -r
'var_dump(explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ",
-1e99));'
Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried
to allocate 18446744073383068122 bytes) in Command line code on line
1
# build/php_5_3/sapi/cli/php -n -dmemory_limit=2G -r
'var_dump(explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ",
-1e99));'
Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried
to allocate 3792765909 bytes) in Command line code on line 1
# build/php_5_2/sapi/cli/php -n -dmemory_limit=2G -r
'var_dump(explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ",
-1e99));'
array(1) {
[0]=>
string(43) " 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 "
}
[2009-03-31 19:15:47] disas at mail dot ru
Description:
Bug on result where negative or positive number of limit is very high.
Reproduce code:
---
#Code:
var_export(
explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ", -1e99)
);
#Result:
array (
0 => ' 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ',
);
#Code:
var_export(
explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ", -1e9)
);
#Result:
array (
)
Expected result:
array (
0 => ' 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ',
);
Actual result:
--
I think that in both cases the result should be:
array(
)
--
Edit this bug report at http://bugs.php.net/?id=47854&edit=1
#48082 [Fbk]: mysql_connect not work with named pipes
ID: 48082
Updated by: matt...@php.net
Reported By: andrew dot answer at gmail dot com
Status: Feedback
Bug Type: MySQL related
Operating System: Windows XP
PHP Version: 5.3.0RC1
New Comment:
No it's not Jani. :-)
Confirmed. Looks like it's with the VC9 binaries -- is that what you
are using (not VC6)? Another difference related to getaddrinfo...
'' (empty string) and 'localhost' work. BTW localhost is actually using
TCP/IP, contrary to what the manual says. Also (even in 5.2), the empty
string is also changing to localhost -- I'm not sure when the behavior
changed (or if it's MySQL server-related), but that used to use a named
pipe without needing to specify '.' :-/
Previous Comments:
[2009-04-26 21:07:14] j...@php.net
What if you pass proper parameters? "." as host is quite invalid..
[2009-04-26 18:31:40] andrew dot answer at gmail dot com
Description:
When mysql server setting up on WinXP machine with named pipe,
mysql_connect called with '.' as host parameter anyway connect via
tcp:// protocol.
Reproduce code:
---
When mysql server setting up on WinXP machine with options
[client]
pipe
socket=mysql
[mysqld]
skip-networking
enable-named-pipe
socket=mysql
php code like this:
$link = mysql_connect('.','user','password');
if (!$link) {
die('Could not connect: ' . mysql_error());
} else echo 'Connected successfully';
mysql_close($link);
should connect via named pipes. But it's fail.
Expected result:
Connected successfully
Actual result:
--
Could not connect: php_network_getaddresses: getaddrinfo failed: Ýòîò
õîñò íåèçâåñòåí.
php errorlog:
[27-Apr-2009 01:28:06] PHP Warning: mysql_connect():
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñòåí.
in C:\sites\www\php.php on line 10
[27-Apr-2009 01:28:06] PHP Warning: mysql_connect(): [2002]
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñò
(trying to connect via tcp://.:3306) in C:\sites\www\php.php on line
10
[27-Apr-2009 01:28:06] PHP Warning: mysql_connect():
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñòåí.
in C:\sites\www\php.php on line 10
--
Edit this bug report at http://bugs.php.net/?id=48082&edit=1
#48082 [Fbk->Ver]: mysql_connect not work with named pipes
ID: 48082
Updated by: matt...@php.net
Reported By: andrew dot answer at gmail dot com
-Status: Feedback
+Status: Verified
Bug Type: MySQL related
Operating System: Windows XP
PHP Version: 5.3.0RC1
Previous Comments:
[2009-04-27 00:04:04] matt...@php.net
No it's not Jani. :-)
Confirmed. Looks like it's with the VC9 binaries -- is that what you
are using (not VC6)? Another difference related to getaddrinfo...
'' (empty string) and 'localhost' work. BTW localhost is actually using
TCP/IP, contrary to what the manual says. Also (even in 5.2), the empty
string is also changing to localhost -- I'm not sure when the behavior
changed (or if it's MySQL server-related), but that used to use a named
pipe without needing to specify '.' :-/
[2009-04-26 21:07:14] j...@php.net
What if you pass proper parameters? "." as host is quite invalid..
[2009-04-26 18:31:40] andrew dot answer at gmail dot com
Description:
When mysql server setting up on WinXP machine with named pipe,
mysql_connect called with '.' as host parameter anyway connect via
tcp:// protocol.
Reproduce code:
---
When mysql server setting up on WinXP machine with options
[client]
pipe
socket=mysql
[mysqld]
skip-networking
enable-named-pipe
socket=mysql
php code like this:
$link = mysql_connect('.','user','password');
if (!$link) {
die('Could not connect: ' . mysql_error());
} else echo 'Connected successfully';
mysql_close($link);
should connect via named pipes. But it's fail.
Expected result:
Connected successfully
Actual result:
--
Could not connect: php_network_getaddresses: getaddrinfo failed: Ýòîò
õîñò íåèçâåñòåí.
php errorlog:
[27-Apr-2009 01:28:06] PHP Warning: mysql_connect():
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñòåí.
in C:\sites\www\php.php on line 10
[27-Apr-2009 01:28:06] PHP Warning: mysql_connect(): [2002]
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñò
(trying to connect via tcp://.:3306) in C:\sites\www\php.php on line
10
[27-Apr-2009 01:28:06] PHP Warning: mysql_connect():
php_network_getaddresses: getaddrinfo failed: Ýòîò õîñò íåèçâåñòåí.
in C:\sites\www\php.php on line 10
--
Edit this bug report at http://bugs.php.net/?id=48082&edit=1
#44681 [Opn]: Resources used as array keys get converted to 0
ID: 44681
Updated by: [EMAIL PROTECTED]
Reported By: ilewis at uk dot ibm dot com
Status: Open
Bug Type: Arrays related
Operating System: Windows XP SP2
PHP Version: 5.3CVS-2008-04-10 (snap)
New Comment:
This was introduced after the Jan 23rd changes to zend_execute.c,
causing the resource ID to be read as a double. case statements just
need to be rearranged. :-)
I also noticed that trying to use a resource key like array($fres =>
'bob') doesn't work (never has) and just gives "Illegal offset type."
Seems like it should be consistent either way? The following patches
also make that work, if they want to add it.
http://realplain.com/php/bug44681.diff
http://realplain.com/php/bug44681_5_3.diff
Previous Comments:
[2008-04-10 09:32:56] ilewis at uk dot ibm dot com
Description:
Using todays prebuilt snap of 5.3 on Windows, it looks like resources
being used as array keys are being converted to int(0). The prevents
them being used as unique array keys. This is a big change from php
5.2.5,
Reproduce code:
---
Expected result:
PHP Strict Standards: Resource ID#5 used as offset, casting to integer
(5) in G:\tmp\arraytest.php on line 15
PHP Strict Standards: Resource ID#6 used as offset, casting to integer
(6) in G:\tmp\arraytest.php on line 16
array(4) {
[0]=>
int(1)
[1]=>
int(2)
[5]=>
string(3) "bob"
[6]=>
string(4) "bob2"
}
Actual result:
--
Strict Standards: Resource ID#5 used as offset, casting to integer (5)
in G:\tmp\arraytest.php on line 15
Strict Standards: Resource ID#6 used as offset, casting to integer (6)
in G:\tmp\arraytest.php on line 16
array(2) {
[0]=>
string(4) "bob2"
[1]=>
int(2)
}
--
Edit this bug report at http://bugs.php.net/?id=44681&edit=1
#44830 [Opn]: Very minor issue with backslash in heredoc
ID: 44830 Updated by: [EMAIL PROTECTED] Reported By: slattery at uk dot ibm dot com Status: Open Bug Type: Scripting Engine problem Operating System: windows PHP Version: 5.2.5 New Comment: Yeah, good catch. (And a backslash would actually always be lost at the end of a heredoc, even with other text before it.) Because of a check in the loop that scans for escape sequences, the \ becomes \0 (null byte). For the devs: I removed the additional check for end of string. All that will happen with this reproduce code is variable "s" will be incremented past the end of the string at the end of the while () -- but I believe that's safe because it won't be read from afterwards. Patches for all 3 branches: http://realplain.com/php/bug44830.diff http://realplain.com/php/bug44830_5_3.diff http://realplain.com/php/bug44830_5_2.diff Previous Comments: [2008-04-25 11:21:28] slattery at uk dot ibm dot com Description: There is a very minor issue when a heredoc contains only a single backslash. The doc says heredoc behaves exactly as double quoted string - so in this one particular case of the single backslash - we have a case which cannot be produced in a double quoted string - so the behaviour is undefined. The engine appears to treat is as a 'record separator', but I think it would be better treated as a backslash. Im quite happy for this to be closed as bogus - Its just that the code below is from a php test case - I dont suppose anyone will actually do this. Reproduce code: --- Expected result: On running the code I get: string(2) "00" string(4) "5c30" string(2) "00" which looks a little strange, I would have expected: string(2) "5c" string(4) "5c5c" string(2) "5c" -- Edit this bug report at http://bugs.php.net/?id=44830&edit=1
#44681 [Opn->Csd]: Resources used as array keys get converted to 0
ID: 44681
Updated by: [EMAIL PROTECTED]
Reported By: ilewis at uk dot ibm dot com
-Status: Open
+Status: Closed
Bug Type: Arrays related
Operating System: Windows XP SP2
PHP Version: 5.3CVS-2008-04-10 (snap)
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Just fixed the reported bug with resources used as offsets:
$myarray[$fres]. They will still give "Illegal offset type" (as always)
if used as an index in an array( ... ) construct. I wasn't sure if that
should be changed to be consistent...
Previous Comments:
[2008-04-13 10:42:25] [EMAIL PROTECTED]
This was introduced after the Jan 23rd changes to zend_execute.c,
causing the resource ID to be read as a double. case statements just
need to be rearranged. :-)
I also noticed that trying to use a resource key like array($fres =>
'bob') doesn't work (never has) and just gives "Illegal offset type."
Seems like it should be consistent either way? The following patches
also make that work, if they want to add it.
http://realplain.com/php/bug44681.diff
http://realplain.com/php/bug44681_5_3.diff
[2008-04-10 09:32:56] ilewis at uk dot ibm dot com
Description:
Using todays prebuilt snap of 5.3 on Windows, it looks like resources
being used as array keys are being converted to int(0). The prevents
them being used as unique array keys. This is a big change from php
5.2.5,
Reproduce code:
---
Expected result:
PHP Strict Standards: Resource ID#5 used as offset, casting to integer
(5) in G:\tmp\arraytest.php on line 15
PHP Strict Standards: Resource ID#6 used as offset, casting to integer
(6) in G:\tmp\arraytest.php on line 16
array(4) {
[0]=>
int(1)
[1]=>
int(2)
[5]=>
string(3) "bob"
[6]=>
string(4) "bob2"
}
Actual result:
--
Strict Standards: Resource ID#5 used as offset, casting to integer (5)
in G:\tmp\arraytest.php on line 15
Strict Standards: Resource ID#6 used as offset, casting to integer (6)
in G:\tmp\arraytest.php on line 16
array(2) {
[0]=>
string(4) "bob2"
[1]=>
int(2)
}
--
Edit this bug report at http://bugs.php.net/?id=44681&edit=1
#44830 [Opn->Csd]: Very minor issue with backslash in heredoc
ID: 44830 Updated by: [EMAIL PROTECTED] Reported By: slattery at uk dot ibm dot com -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: windows PHP Version: 5.2.5 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-04-28 13:04:49] [EMAIL PROTECTED] Yeah, good catch. (And a backslash would actually always be lost at the end of a heredoc, even with other text before it.) Because of a check in the loop that scans for escape sequences, the \ becomes \0 (null byte). For the devs: I removed the additional check for end of string. All that will happen with this reproduce code is variable "s" will be incremented past the end of the string at the end of the while () -- but I believe that's safe because it won't be read from afterwards. Patches for all 3 branches: http://realplain.com/php/bug44830.diff http://realplain.com/php/bug44830_5_3.diff http://realplain.com/php/bug44830_5_2.diff [2008-04-25 11:21:28] slattery at uk dot ibm dot com Description: There is a very minor issue when a heredoc contains only a single backslash. The doc says heredoc behaves exactly as double quoted string - so in this one particular case of the single backslash - we have a case which cannot be produced in a double quoted string - so the behaviour is undefined. The engine appears to treat is as a 'record separator', but I think it would be better treated as a backslash. Im quite happy for this to be closed as bogus - Its just that the code below is from a php test case - I dont suppose anyone will actually do this. Reproduce code: --- Expected result: On running the code I get: string(2) "00" string(4) "5c30" string(2) "00" which looks a little strange, I would have expected: string(2) "5c" string(4) "5c5c" string(2) "5c" -- Edit this bug report at http://bugs.php.net/?id=44830&edit=1
#45042 [Opn]: Vista & mySQL Extension = slowdown when PHP finalizes
ID: 45042 Updated by: [EMAIL PROTECTED] Reported By: php at schubec dot com Status: Open Bug Type: Performance problem Operating System: Vista (any version) PHP Version: 5.2.6 New Comment: I assume this is from the "Error in my_thread_global_end(): 1 threads didn't exit" thing: see Bug #41350, or Google... I had noticed it in CLI (but not Apache module), but hadn't looked into it since I thought maybe I had messed something up with different PHP builds, etc., but it definitely looks like it's still a widespread issue? Previous Comments: [2008-05-20 09:51:36] php at schubec dot com Sorry, but what info are you missing? I read the "how to post bugs" page, but I do not see what I am missing. Thank you, Bernhard [2008-05-19 22:44:28] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2008-05-19 22:13:25] php at schubec dot com Description: When you activate the mySQL Extension on Vista, PHP is delayed for about 3-4 seconds after every script execution. As far as I found out this happens when PHP finalizes (so something like a destructor or so). Problem can be reproduced. Even if NO mySQL related code is called!!! I am using a CLI version of PHP 5.2.6. The problem can also be reproduced when you use SAPI to embed PHP in you own application. I did not test that with IIS/Apache or any other webserver. Reproduce code: --- //Any code will do echo "Hello World"; //This takes about 5 secs to execute on Vista with mySQL Extensions on. Expected result: Either a delay only when something mySQL related is used (eg: mysql_connect) or no noticable delay at all. Actual result: -- Every script is delayed 5 seconds. -- Edit this bug report at http://bugs.php.net/?id=45042&edit=1
#45068 [Opn->Fbk]: Large integer immediates are read incorrectly
ID: 45068 Updated by: [EMAIL PROTECTED] Reported By: philipm at sybase dot com -Status: Open +Status: Feedback Bug Type: Variables related Operating System: Linux (32-bit only) PHP Version: 5.2.6 New Comment: This would seem to be caused by SIZEOF_LONG not being defined correctly (e.g. 8 when it should be 4 on 32-bit)... I'm the one who made the changes in 5.2.1 so most of the overhead to check for integer overflow could be eliminated, etc. It didn't cause any tests to fail, and this is the first issue I've heard. Also, I would expect numeric strings to fail in the same way: '30' + 0 ? Is the result the same if you use an 11-digit number? Any more details about your Linux system, in case there's something unique, might help the Linux experts (not me) figure something else out. I'm not sure what sets SIZEOF_LONG. Oh wait, I was just looking at the configure script, and noticed bits about "cross compiling" where SIZEOF_LONG is defined -- do you know, is that something that applies in your configuration? Previous Comments: [2008-05-22 19:34:15] philipm at sybase dot com Description: Entering a large integer immediate (i.e. bigger than INT_MAX) will result in INT_MAX being used. The issue is that these numbers cannot be treated as integers in the zval, but for some reason the parser is attempting to do so. However, the various operators convert the large number to a float, so they work okay. For example, entering: 30 gives 2147483647 30 + 1 gives 2147483648 30.0 + 1 gives 31 This issue was introduced in PHP 5.2.1 and has not been addressed as of 5.2.6. 5.2.0 and earlier worked as expected. It also appears to work properly on Windows. Reproduce code: --- # the output should be the same as the input print 30 . "\n"; # these two should be the same print 30 + 1 . "\n"; print 30.0 + 1 ."\n"; Expected result: 30 31 31 Actual result: -- 2147483647 2147483648 31 -- Edit this bug report at http://bugs.php.net/?id=45068&edit=1
#45348 [Opn->Bgs]: array_keys() convert string to integer
ID: 45348
Updated by: [EMAIL PROTECTED]
Reported By: songqi at baidu dot com
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: Redhat Linux
PHP Version: 5.2.6
New Comment:
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
No, array_keys() isn't doing that. Numeric strings used as an array key
are converted to integer when the element is created. This can be seen
by removing array_keys() from your code:
'abc','a'=>'1');
var_dump($a);
?>
And you will see:
array(2) {
[1]=>
string(3) "abc"
["a"]=>
string(1) "1"
}
(Notice no quotes around the integer key.) And NOT:
array(2) {
["1"]=>
string(3) "abc"
["a"]=>
string(1) "1"
}
Previous Comments:
[2008-06-24 11:34:28] songqi at baidu dot com
Description:
just look at the example
Reproduce code:
---
'abc','a'=>'1');
var_dump(array_keys($a));
?>
Expected result:
array(2) {
[0]=>
string(1) "1"
[1]=>
string(1) "a"
}
Actual result:
--
array(2) {
[0]=>
int(1)
[1]=>
string(1) "a"
}
--
Edit this bug report at http://bugs.php.net/?id=45348&edit=1
#45372 [Ctl]: hash# check in new re2c parser breaks code
ID: 45372
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 5.3CVS-2008-06-27 (CVS)
New Comment:
(yyless(1) could just be used before the goto...)
Anyway, did you actually try that? AFAIK it still won't work, at least
with your single line example (which there's already been at least one
report about). While the local code fix is correct, the re2c code/logic
seems flawed to me. (Maybe this bug report can be about that instead, in
general, since I didn't get around to sending a follow-up message to the
internals@ list yet, explaining things. :-))
In this example, it will still be broken because of the YYFILL() check
-- each time it checks if the next character can match, even when it's
at the end of the input. YYFILL() then makes it return, completely
ignoring anything that has matched up to that point!
I'm not sure if this explanation is 100% correct, but I believe this
wrong behavior happens when EOF is encountered while trying to match the
variable length part of ANY rule; or something close to that. :-) It's
been over a month since I tried to track and figure out what was
happening. Granted, most of the cases (unlike yours), where the match is
aborted because of YYFILL(), it's with invalid code, but it shouldn't
happen. BTW, I think the part with the inline_char_handler label where
it looks for opening PHP tags in the HTML, while a good optimization
(using memchr() to find < etc.), was actually added as a workaround for
this re2c/YYFILL() behavior. I didn't try it, but from what I've
observed, I think whatever plain HTML was at the end of a file would
have been lost if a regular rule (like in Flex) was used to match it...
Oh, there are also some more bugs in the code that looks for opening
PHP tag, but they wouldn't be found as easily as this (and haven't been
reported so far). I think I know how it can be fixed nicely, along with
some more other scanner optimizations (for inline HTML and comments,
basically). But I haven't done anything yet since some of it won't even
work with these re2c/YYFILL() issues. :-/
Finally, to simplify what I think is the basic, underlying flaw with
the code of re2c and YYFILL() now, here's a super easy example. Say you
have one rule:
[a-z]+
It will NEVER match any input that a person would think, such as the
string "foo" -- seems pretty messed up to me!?
Previous Comments:
[2008-06-27 06:03:16] [EMAIL PROTECTED]
marking as critical
[2008-06-27 06:00:54] [EMAIL PROTECTED]
Description:
single line file:
#
produces a parse error:
get's caught with this rule from the re2c scanner.
"#".+ {NEWLINE} {
if ((YYCTYPE*)yytext == SCNG(yy_start)) {
/* ignore first line when it's started with a # */
goto restart;
} else {
goto inline_char_handler;
}
}
basically the scanner runs off the end, and eats everything after the
#
I've fixed it by changing the above to something like:
} else {
/* shunt back to just return the # on it's own.. */
YYCURSOR = YYMARKER;
yyleng = 1;
goto inline_char_handler;
}
--
Edit this bug report at http://bugs.php.net/?id=45372&edit=1
#45384 [Opn]: parse_ini_file will result in parse error with no trailing newline
ID: 45384
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Filesystem function related
Operating System: Ubuntu
PHP Version: 5.3CVS-2008-06-28 (CVS)
New Comment:
This is probably also related to the re2c/YYFILL() scanner issues I
described in Bug #45372.
I assume it's because a variable length rule is matching ("baz" in your
example) when it hits EOF and YYFILL() causes a return/abort. This
(unexpected $end) is more likely to happen with ini parsing, etc. where
it doesn't usually happen with VALID code in a PHP script because the
last thing matched in a typical file is with a fixed length rule (e.g.
"?>" or ";"), and these things only happen with variable length matches
as I explained in the other bug, though they shouldn't with working
scanner code, IMO.
BTW, does putting a space or something other than a newline after baz
allow it to work? Any character that's not allowed in the rule matching
baz should also make it "magically" work. :-)
Previous Comments:
[2008-06-28 03:05:49] [EMAIL PROTECTED]
Description:
an ini file with no trailing newline will result in "Parse error",
php5.3 only, 5.2 parses the file fine
Reproduce code:
---
$ echo -n "foo.bar = baz" > test.ini
$ /opt/php53/bin/php -r 'var_dump(parse_ini_file("test.ini"));'
Expected result:
array(1) {
["foo.bar"]=>
string(3) "baz"
}
Actual result:
--
Warning: syntax error, unexpected $end in test.ini on line 1
in Command line code on line 1
Call Stack:
0.0003 312916 1. {main}() Command line code:0
0.0128 312936 2. parse_ini_file() Command line code:1
array(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=45384&edit=1
#45372 [Csd->Opn]: hash# check in new re2c parser breaks code
ID: 45372
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 5.3CVS-2008-06-27 (CVS)
Assigned To: helly
New Comment:
This is not fixed, actually (is it OK to change Status back to Open?).
Nuno, I saw your commit yesterday, which didn't seem like it would help
(as it wasn't related to what I said above), but wanted to wait until I
could check again to make sure I wasn't crazy with my above description.
:-)
I just tried the latest Windows snapshot and it's still generating a
parse error with the *single line file* (no newline at the end, which .+
won't match, therefore won't trigger the YYFILL() "return 0" thing)
descibed in this report (and the CLI example in Bug #44654). Can't be
only broken on Windows since everything uses the same generated scanner
code...
Something like Alan's scanning loop could be done after just matching
#, BUT that's just another workaround for that underlying re2c/YYFILL()
problem (also affecting other things). I believe if you use the
tokenizer extension, you can see that if the last token of code is
matched by a variable length rule, it won't be returned. e.g. my example
of a simple rule, [a-z]+ not matching input "foo"
Previous Comments:
[2008-07-06 17:01:55] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2008-06-27 14:57:57] [EMAIL PROTECTED]
Not sure why re2c needs to deal with the #bang situation
looking at the code it would be better to eat that line outside of the
lexer..
Something like:
int ini_lex(zval *ini_lval TSRMLS_DC)
{
if ((YYCTYPE*)yytext == SCNG(yy_start) && *yych == '#') {
while(*yych != '\n' && *yych != '\n' && yych < yyend) {
yych++;
}
while((*yych == '\n' || *yych == '\n') && yych < yyend) {
yych++;
}
YYCURSOR = yych;
}
.
[2008-06-27 11:26:18] [EMAIL PROTECTED]
Duplicated... Bug #45147
[2008-06-27 09:31:21] [EMAIL PROTECTED]
This should work like in older releases, Marcus please check it!
[2008-06-27 09:05:48] [EMAIL PROTECTED]
(yyless(1) could just be used before the goto...)
Anyway, did you actually try that? AFAIK it still won't work, at least
with your single line example (which there's already been at least one
report about). While the local code fix is correct, the re2c code/logic
seems flawed to me. (Maybe this bug report can be about that instead, in
general, since I didn't get around to sending a follow-up message to the
internals@ list yet, explaining things. :-))
In this example, it will still be broken because of the YYFILL() check
-- each time it checks if the next character can match, even when it's
at the end of the input. YYFILL() then makes it return, completely
ignoring anything that has matched up to that point!
I'm not sure if this explanation is 100% correct, but I believe this
wrong behavior happens when EOF is encountered while trying to match the
variable length part of ANY rule; or something close to that. :-) It's
been over a month since I tried to track and figure out what was
happening. Granted, most of the cases (unlike yours), where the match is
aborted because of YYFILL(), it's with invalid code, but it shouldn't
happen. BTW, I think the part with the inline_char_handler label where
it looks for opening PHP tags in the HTML, while a good optimization
(using memchr() to find < etc.), was actually added as a workaround for
this re2c/YYFILL() behavior. I didn't try it, but from what I've
observed, I think whatever plain HTML was at the end of a file would
have been lost if a regular rule (like in Flex) was used to match it...
Oh, there are also some more bugs in the code that looks for opening
PHP tag, but they wouldn't be found as easily as this (and haven't been
reported so far). I think I know how it can be fixed nicely, along with
some more other scanner optimizations (for inline HTML and comments,
basically). But I haven't done anything yet since some of it won't even
work with these re2c/YYFILL() issues. :-/
Finally, to simplify what I think is the basic, underlying flaw with
the code of re2c and YYFILL() now, here's a super easy example. Say you
have one rule:
[a-z]+
It will NEVER match any input that a person would think, such as the
string "foo" -- seems p
