Bug #60471 [Com]: Random "Invalid request (unexpected EOF)" using a router script
Edit report at https://bugs.php.net/bug.php?id=60471&edit=1 ID: 60471 Comment by: pascal dot chevrel at free dot fr Reported by:lolautruche at gmail dot com Summary:Random "Invalid request (unexpected EOF)" using a router script Status: Assigned Type: Bug Package:Built-in web server Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.4.0RC2 Assigned To:laruence Block user comment: N Private report: N New Comment: Just in case it matters, I am seeing the same bug on Linux with Firefox (both Firefox releases and Nightly builds) Previous Comments: [2012-02-25 15:15:24] michal dot pipa dot xsolve at gmail dot com I've attached a patch that disables "Unexpected EOF" error message from built-in server. [2012-02-23 18:45:53] michal dot pipa dot xsolve at gmail dot com I've noticed these messages and did some network traffic analysis. I've tested this on Ubuntu and Chromium. What I've found is that Chromium has feature called "Predict network actions to improve page load performance" and it's enabled by default. It works this way, that if HTML page has links to some resources, than Chromium opens about 10 TCP connections in advance. And then if browser has less than 10 resources to fetch, unused connections times out after 10 seconds. And this (empty payload) causes PHP server to display "Invalid request (unexpected EOF)" message. See: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/sapi/cli/php_cli_server.c?revision=322966&view=markup#l1591 When you disable this Chromium's feature it doesn't open TCP connections in advance and this error message disappears. I'm wondering if we really need this error message (maybe it was used for some debugging purposes). [2012-02-16 18:29:02] ras...@php.net The patch is here: http://svn.php.net/viewvc/php/php-src/trunk/sapi/cli/php_cli_server.c? r1=323078&r2=323077&pathrev=323078&view=patch if someone could test it, please. [2012-02-16 18:24:54] ras...@php.net Could this simply be caused by the "Connection: closed" message instead of the correct "Connection: close" message the built-in server spits out? This is fixed in trunk but hasn't been merged to 5.4 yet. [2012-02-12 17:06:17] rbrunius at gmail dot com I'm am having the same thing happen and I Googled error code it and found this thread. I tried various ways to terminate the file but none solved it. php 5.4 RC7 development server on Windows 7 Chrome browser has brings the issue but Firefox does not. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60471 -- Edit this bug report at https://bugs.php.net/bug.php?id=60471&edit=1
Bug #60471 [Asn]: Random "Invalid request (unexpected EOF)" using a router script
Edit report at https://bugs.php.net/bug.php?id=60471&edit=1 ID: 60471 Updated by: larue...@php.net Reported by:lolautruche at gmail dot com Summary:Random "Invalid request (unexpected EOF)" using a router script Status: Assigned Type: Bug Package:Built-in web server Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.4.0RC2 Assigned To:laruence Block user comment: N Private report: N New Comment: Hey, actually, this warnnig message is no harm. Previous Comments: [2012-10-24 07:36:36] pascal dot chevrel at free dot fr Just in case it matters, I am seeing the same bug on Linux with Firefox (both Firefox releases and Nightly builds) [2012-02-25 15:15:24] michal dot pipa dot xsolve at gmail dot com I've attached a patch that disables "Unexpected EOF" error message from built-in server. [2012-02-23 18:45:53] michal dot pipa dot xsolve at gmail dot com I've noticed these messages and did some network traffic analysis. I've tested this on Ubuntu and Chromium. What I've found is that Chromium has feature called "Predict network actions to improve page load performance" and it's enabled by default. It works this way, that if HTML page has links to some resources, than Chromium opens about 10 TCP connections in advance. And then if browser has less than 10 resources to fetch, unused connections times out after 10 seconds. And this (empty payload) causes PHP server to display "Invalid request (unexpected EOF)" message. See: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/sapi/cli/php_cli_server.c?revision=322966&view=markup#l1591 When you disable this Chromium's feature it doesn't open TCP connections in advance and this error message disappears. I'm wondering if we really need this error message (maybe it was used for some debugging purposes). [2012-02-16 18:29:02] ras...@php.net The patch is here: http://svn.php.net/viewvc/php/php-src/trunk/sapi/cli/php_cli_server.c? r1=323078&r2=323077&pathrev=323078&view=patch if someone could test it, please. [2012-02-16 18:24:54] ras...@php.net Could this simply be caused by the "Connection: closed" message instead of the correct "Connection: close" message the built-in server spits out? This is fixed in trunk but hasn't been merged to 5.4 yet. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60471 -- Edit this bug report at https://bugs.php.net/bug.php?id=60471&edit=1
Req #26934 [Com]: error logging should log url for each page
Edit report at https://bugs.php.net/bug.php?id=26934&edit=1
ID: 26934
Comment by: moreeasy at gmail dot com
Reported by:Xuefer at 21cn dot com
Summary:error logging should log url for each page
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: *
PHP Version:5CVS-2004-01-16 (dev)
Block user comment: N
Private report: N
New Comment:
I've found useful using register_shutdown_function() at the start of my scripts
register_shutdown_function('shutdownFunction');
function shutDownFunction() {
$error = error_get_last();
print_r($error);
}
Previous Comments:
[2007-09-27 05:30:26] jbyers at gmail dot com
This would be tremendously useful for debugging issues on high-traffic sites.
Just the timestamp isn't sufficient when there are high numbers of requests for
that second.
[2004-01-16 08:49:09] Xuefer at 21cn dot com
Description:
don't know if this feature is request before(i searched, not found)
there're many times error show in my log files
1.
[16-Jan-2004 21:38:42] PHP Warning: Unknown(): A session is active. You cannot
change the session module's ini settings at this time. in Unknown on line 0
2.
[16-Jan-2004 21:38:47] PHP Fatal error: Maximum execution time of 30 seconds
exceeded in /path/to/file.inc.php on line 113
but i don't know which request url cause the above error
there're too many pages include file /path/to/file.inc.php
what a hard life~
please add init setting:
error_log_request_url (boolean) default: true
[16-Jan-2004 21:38:42] PHP REQUEST: GET www.domain.com/abc.php
[16-Jan-2004 21:38:42] PHP Warning: etc etc..
[16-Jan-2004 21:38:43] PHP Fatal error: etc etc..
--
Edit this bug report at https://bugs.php.net/bug.php?id=26934&edit=1
Bug #53228 [Com]: memory leak when throwing exception in custom handler in functions
Edit report at https://bugs.php.net/bug.php?id=53228&edit=1 ID: 53228 Comment by: jille at hexon dot cx Reported by:kgrecki at gmail dot com Summary:memory leak when throwing exception in custom handler in functions Status: Open Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: This is not a bug. If you unset($e); you don't leak any memory. It is because exceptions include a backtrace, containing all the arguments given to the error handling closure. The fifth argument given is $context, an array containing all local variables, including the previous $e. Previous Comments: [2010-11-04 17:14:07] uramihsayibok at gmail dot com unset($e)ing in the catch block plugs the hole - the previous value/exception in $e isn't being destroyed? [2010-11-02 18:48:12] kgrecki at gmail dot com Description: I encountered a similar issue to #25335 where custom error handler + exceptions leaks memory but only when try-catch block is in a function and looped through directly. I imagine there's some scope/GC issues here, and whether this is actual bug or limitation of PHP. Test script: --- https://bugs.php.net/bug.php?id=53228&edit=1
Bug #63297 [Opn->Csd]: Phar fails to write an openssl based signature
Edit report at https://bugs.php.net/bug.php?id=63297&edit=1
ID: 63297
Updated by: a...@php.net
Reported by:a...@php.net
Summary:Phar fails to write an openssl based signature
-Status: Open
+Status: Closed
Type: Bug
Package:PHAR related
Operating System: irrelevant
PHP Version:5.3Git-2012-10-17 (Git)
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of ab
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=a88379e03d806a1218926e9bf2c9bcd74c4124c7
Log: Fixed bug #63297 Phar fails to write an openssl based signature
Previous Comments:
[2012-10-23 15:30:40] a...@php.net
I've tried with the following snippet:
= START SNIPPET
#include
#include
#include
#include
int
main(int argc, char *argv[])
{
EVP_MD_CTX *mdctx = NULL;
unsigned char sign_value[1024];
int sign_len, i;
EVP_PKEY *pkey = NULL;
RSA *rpkey = NULL;
FILE *rpkey_file;
mdctx = EVP_MD_CTX_create();
rpkey_file = fopen("./rsa.key", "r");
if (!rpkey_file) {
return 3;
}
PEM_read_RSAPrivateKey(rpkey_file, &rpkey, NULL, NULL);
pkey = EVP_PKEY_new();
EVP_PKEY_set1_RSA(pkey, rpkey);
EVP_SignInit_ex(mdctx, EVP_sha1(), NULL);
EVP_SignUpdate(mdctx, "abracadabra0", strlen("abracadabra0"));
EVP_SignUpdate(mdctx, "abracadabra1", strlen("abracadabra1"));
EVP_SignUpdate(mdctx, "abracadabra2", strlen("abracadabra2"));
EVP_SignUpdate(mdctx, "abracadabra3", strlen("abracadabra3"));
EVP_SignUpdate(mdctx, "abracadabra4", strlen("abracadabra4"));
EVP_SignFinal(mdctx, sign_value, (unsigned int *)&sign_len, pkey);
sign_value[sign_len] = '\0';
EVP_MD_CTX_destroy(mdctx);
printf("Signature is: ");
for(i = 0; i < sign_len; i++) {
printf("%02x", sign_value[i]);
}
printf("\n");
fclose(rpkey_file);
return 0;
}
= END SNIPPET
It does the same thing as the code in the phar extension producing a signature.
Running that with valgrind gives a bunch of messages about openssl. After
reading the openssl wiki http://www.openssl.org/support/faq.html#PROG13 I think
the actual issue here is that no cleanup is performed on openssl, but that's a
more global issue.
Thus, there is no clean run with or without the patch using valgrind. But the
patch fixes the test run on windows, so i think it's worth to apply it.
[2012-10-23 09:20:20] a...@php.net
Note that the previous trace was produced on CentOS using openssl 1.0.0 where
under windows the bug shows up with openssl 0.9.8x .
[2012-10-23 08:50:14] a...@php.net
Running with the valgrind, there is the following trace:
==22867== Use of uninitialised value of size 4
==22867==at 0x829FFF2: phar_hex_str (util.c:1641)
==22867==by 0x82A0ED4: phar_create_signature (util.c:2212)
==22867==by 0x82A5923: phar_tar_flush (tar.c:1159)
==22867==by 0x82C4CDF: phar_flush (phar.c:2611)
==22867==by 0x82D31DD: zim_Phar_setSignatureAlgorithm (phar_object.c:3124)
==22867==by 0x85AE738: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:320)
==22867==by 0x85AEDDA: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:425)
==22867==by 0x85ADC35: execute (zend_vm_execute.h:107)
==22867==by 0x857C919: zend_execute_scripts (zend.c:1236)
==22867==by 0x8505EB0: php_execute_script (main.c:2308)
==22867==by 0x864F24A: main (php_cli.c:1189)
==22867==
==22867== Use of uninitialised value of size 4
==22867==at 0x82A0019: phar_hex_str (util.c:1642)
==22867==by 0x82A0ED4: phar_create_signature (util.c:2212)
==22867==by 0x82A5923: phar_tar_flush (tar.c:1159)
==22867==by 0x82C4CDF: phar_flush (phar.c:2611)
==22867==by 0x82D31DD: zim_Phar_setSignatureAlgorithm (phar_object.c:3124)
==22867==by 0x85AE738: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:320)
==22867==by 0x85AEDDA: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:425)
==22867==by 0x85ADC35: execute (zend_vm_execute.h:107)
==22867==by 0x857C919: zend_execute_scripts (zend.c:1236)
==22867==by 0x8505EB0: php_execute_script (main.c:2308)
==22867==by 0x864F24A: main (php_cli.c:1189)
==22867==
==22867==
==22867== Syscall param write(buf) points to uninitialised byte(s)
==22867==at 0x24E363: __write_nocancel (syscall-template.S:82)
==22867==by 0x851F8A9: _php_stream_write_buffer (streams.c:1055)
==22867==by 0x851FB5D: _php_stream_write (streams.c:1166)
==22867==by 0x82A5A75: phar_tar_flush (tar.c:1190)
==22867==by 0x82C4CDF: phar_flush (phar.c:2611)
==22867==by 0x82D31DD: zim_Phar_setSignatureAlgorithm (phar_object.c:3124)
==22
Bug #48725 [Com]: Support for flushing in zlib stream
Edit report at https://bugs.php.net/bug.php?id=48725&edit=1
ID: 48725
Comment by: arnout dot boks at moxio dot com
Reported by:slusarz at curecanti dot org
Summary:Support for flushing in zlib stream
Status: Open
Type: Bug
Package:Streams related
Operating System: Linux
PHP Version:5.2.10
Block user comment: N
Private report: N
New Comment:
Verified this with PHP 5.4.7 on Windows.
Another reproduce case:
---
http://stackoverflow.com/questions/7508762/using-zlib-filter-with-a-socket-pair/
[2009-10-23 12:25:10] j...@php.net
It's related, not same. :)
[2009-10-22 21:40:37] slusarz at curecanti dot org
I don't think this is related to bug #49816. Turning off zlib output
compression (by adding "ini_set('zlib.output_compression', 'Off');" to the top
of the test script)doesn't alter the results from the test script previously
reported.
[2009-10-19 15:15:51] j...@php.net
See also bug #49816
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=48725
--
Edit this bug report at https://bugs.php.net/bug.php?id=48725&edit=1
[PHP-BUG] Bug #63347 [NEW]: Different behavior of parameters processing
From: naquad at gmail dot com
Operating system: Linux
PHP version: 5.4.8
Package: PDO related
Bug Type: Bug
Bug description:Different behavior of parameters processing
Description:
PDO::ATTR_EMULATE_PREPARES changes behavior of parameter processing.
When it is enabled multiple occurrences of named parameter work as
expected, but
when it is disabled I get "Invalid parameter number" error.
Test script:
---
setAttribute(PDO::ATTR_EMULATE_PREPARES, false); /// remove this
line and scirpt works as expected
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$query = $pdo->prepare('select :x = :x');
$query->bindValue(':x', 1);
$query->execute();
$t = $query->fetch();
var_dump($t);
$query->closeCursor();
Expected result:
array(2) {
'\'1\' = \'1\'' =>
string(1) "1"
[0] =>
string(1) "1"
}
Actual result:
--
PDOException: SQLSTATE[HY093]: Invalid parameter number in
/srv/http/fucktube/app/test.php on line 7
Call Stack:
0.0002 230552 1. {main}() /srv/http/fucktube/app/test.php:0
0.0739 246416 2. PDOStatement->execute()
/srv/http/fucktube/app/test.php:7
--
Edit bug report at https://bugs.php.net/bug.php?id=63347&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63347&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63347&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63347&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63347&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63347&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63347&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63347&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63347&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63347&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63347&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63347&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63347&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63347&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63347&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63347&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63347&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63347&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63347&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63347&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63347&r=mysqlcfg
[PHP-BUG] Bug #63348 [NEW]: Unexpected behaviour with strpos()
From: aleksey dot v dot korzun at gmail dot com Operating system: *Nix PHP version: 5.3.18 Package: *Programming Data Structures Bug Type: Bug Bug description:Unexpected behaviour with strpos() Description: Please review code snippet below, expected behaviour is that code within if statement will not be executed (since the value was not found). Test script: --- Expected result: It should not output 'fail' Actual result: -- Outputs fail -- Edit bug report at https://bugs.php.net/bug.php?id=63348&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63348&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63348&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63348&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63348&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63348&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63348&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63348&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63348&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63348&r=support Expected behavior: https://bugs.php.net/fix.php?id=63348&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63348&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63348&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63348&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63348&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63348&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63348&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63348&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63348&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63348&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63348&r=mysqlcfg
Bug #55497 [Com]: Credits URL Security ?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000
Edit report at https://bugs.php.net/bug.php?id=55497&edit=1 ID: 55497 Comment by: joaoprabelo at gmail dot com Reported by:mhaisley at gmail dot com Summary:Credits URL Security ?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C1 Status: Not a bug Type: Bug Package:PHP options/info functions Operating System: Any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: nikic, but now I know when PHP is 5.5 or higher easily. Or isn't? Previous Comments: [2012-10-10 17:33:17] ni...@php.net @ian_dunn: The logo GUIDs have been removed in master. So presumably this issue (whether it actually is one or not) will not exist anymore in PHP 5.5. [2012-10-10 17:26:03] ian_dunn at yahoo dot com I agree with mhaisley, this is a security vulnerability and should be disabled by default. Many PCI compliance scanners will fail a site if it is turned on. I realize that it's not a major vulnerability, but it does give attackers information that could help them compromise a system. What are the benefits of having it enabled by default? I can't think of any significant ones. Whatever benefits there are, they'd have to outweigh the downsides, and that doesn't seem likely in this case. [2012-09-12 06:42:41] support at ecommercewebsites dot com dot au Nope - this is not a bug. Just disable it in your config file. [2011-08-25 03:27:29] mhaisley at gmail dot com Sorry, but it is a real issue. It should be disabled by default. [2011-08-25 00:19:08] 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 Attackers can easily brute force without knowing the version. But if youfear this makes things insecure you can set expose_php=Off in php.ini. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55497 -- Edit this bug report at https://bugs.php.net/bug.php?id=55497&edit=1
[PHP-BUG] Bug #63349 [NEW]: Segfault during GC
From: phpwnd at gmail dot com Operating system: Gentoo Linux PHP version: 5.4.8 Package: Reproducible crash Bug Type: Bug Bug description:Segfault during GC Description: PHP 5.4.8 + XDebug 2.2.1, no other extensions I've been experiencing a few segfaults lately. They've been a bit hard to reproduce because so far I've only hit them when using PHP_CodeCoverage and only on specific revisions of my code (adding or removing a single statement such as "$a=1;" would keep it from happening.) I have gotten around rebuilding PHP with all the debug bells and whistles and the resulting backtrace (hopefully attached to this bug) indicates it's related to GC and/or PCRE. Adding a call to gc_collect_cycles() fixed it for me, at least for now. -- Edit bug report at https://bugs.php.net/bug.php?id=63349&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63349&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63349&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63349&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63349&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63349&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63349&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63349&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63349&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63349&r=support Expected behavior: https://bugs.php.net/fix.php?id=63349&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63349&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63349&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63349&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63349&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63349&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63349&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63349&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63349&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63349&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63349&r=mysqlcfg
Bug #29992 [Com]: foreach by reference corrupts the array
Edit report at https://bugs.php.net/bug.php?id=29992&edit=1
ID: 29992
Comment by: newms87 at gmail dot com
Reported by:fletch at pobox dot com
Summary:foreach by reference corrupts the array
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: linux
PHP Version:5.0.1
Block user comment: N
Private report: N
New Comment:
I understand this functionality, and I do agree that it is not a bug. It seems
at the core of PHP that this is what would happen, but it does seem very
unintuitive to me having used a variety of other languages. The result is not
expected and has caused several very hard to find bugs for me.
Would it be possible to have PHP generate a E_NOTICE when using the same $var
in
both a foreach and afterwards when in a higher scope? EG:
foreach($args as &$a){}
$a = 'hello'; // this would generate an E_NOTICE
Then maybe have the option to turn off (or on by default) the E_NOTICE warnings
in the ini settings?
Previous Comments:
[2012-06-29 18:52:20] iam4webwork at hotmail dot com
I appreciate the explanation that Rasmus provides -- thank you!
One small but troublesome detail:
The first foreach changes the array by making $a[1] a reference
variable while $a[0] remains a normal variable.
$a = array(1,2);
foreach($a as &$e){}
var_dump($a,$e); // $a[1] == &int 2$e == 2
foreach($a as $e){} $a[1] == &int 1$e == 1
var_dump($a,$e); // $a[1] now points to last value of $a which is $a[0]
How about adding a switch so that users who don't want or understand
this behavior can turn it off? Then it would be up in front of the
documentation and would be less liable to be overlooked by users who
fail to scroll down to the colored box.
Even if PHP were to have lexical scope (how hard would that be to
implement and why can't PHP evolve that way?), that doesn't change
the fact that the first loop doing seemingly nothing, does change the array.
[2012-05-04 08:04:56] email at stevemann dot net
ras...@php.net asked
"Ok, simple question then. Do you expect this to output 3?"
foreach(array(1,2,3) as $b) { }
echo $b;
I would much prefer it not to output 3. Personally I think it would make a lot
more sense and be a lot safer to have the array element references scoped to
the foreach block - so effectively being unset after the block has run. Having
the last element of the array floating around outside of the block is very
dangerous in my view and can lead to silent errors. As someone else mentioned,
I hate to think how much incorrect data there is out there because of the last
array element being accidentally changed outside of the block.
der...@php.net rather flippantly said:
"no, we can't unset it by default, as people might use this for some weird
reason."
I can think of plenty of non-weird reasons why people might want this
behaviour. But if it was unset by default, it's a simple matter to assign the
reference to a variable defined outside of the block thereby making it
available outside the foreach. In other words, like this:
$c = NULL;
foreach(array(1,2,3) as $b) {
$c = $b;
}
unset($b);// simulates block-scoping of $b
echo $c;
This is not a bug, but I believe it's dangerous behaviour of PHP as it would
seem quite logical to assume that the element references are scoped to the
foreach block only - witness the many comments in this thread to that effect.
So my vote would be to change this behaviour to block-scoping in a future
version.
[2012-03-19 18:51:24] paul dot dillinger at gmail dot com
Rasmus,
Thanks for looking at this. I found the problem. I would still call it a bug,
but I will describe it and you can decide. You are the man after all. You
were
right, I was passing a variable by reference in the few lines of code in front
of my example above:
foreach($this->data['external_'.$type] as &$item){
if(!empty($item['package'])){
$packages[] = $item;
$library_names[] = $item['library_name'];
unset($item);
}
}
/* Code in example above goes here */
BUT, where I see this as a bug was: $packages (the array that was getting
changed) was a new array created from the data of each $item. $packages was
never being referenced, though the variable $item it was created from was. So,
it should be a copy of the data and not THE data right?
I fixed it by simply not trying to pass by reference and changing unset($item)
to unset($this->data['external_'.$type]). Looking at it, that was the way to
do
it from the beginning. I see that, but I'm not sure why $packages gets changed
down the road (it was correct immedi
Bug #63349 [Opn->Fbk]: Segfault during GC
Edit report at https://bugs.php.net/bug.php?id=63349&edit=1 ID: 63349 Updated by: s...@php.net Reported by:phpwnd at gmail dot com Summary:Segfault during GC -Status: Open +Status: Feedback Type: Bug Package:Reproducible crash Operating System: Gentoo Linux PHP Version:5.4.8 Block user comment: N Private report: N New Comment: Thanks for the report. Can you continue working on it and: - Upload a script that reproduces the problem when XDebug is not installed - Upload build & configuration information - Try with zend.enable_gc = Off Previous Comments: [2012-10-24 20:48:11] phpwnd at gmail dot com Description: PHP 5.4.8 + XDebug 2.2.1, no other extensions I've been experiencing a few segfaults lately. They've been a bit hard to reproduce because so far I've only hit them when using PHP_CodeCoverage and only on specific revisions of my code (adding or removing a single statement such as "$a=1;" would keep it from happening.) I have gotten around rebuilding PHP with all the debug bells and whistles and the resulting backtrace (hopefully attached to this bug) indicates it's related to GC and/or PCRE. Adding a call to gc_collect_cycles() fixed it for me, at least for now. -- Edit this bug report at https://bugs.php.net/bug.php?id=63349&edit=1
Bug #63348 [Opn->Nab]: Unexpected behaviour with strpos()
Edit report at https://bugs.php.net/bug.php?id=63348&edit=1 ID: 63348 Updated by: s...@php.net Reported by:aleksey dot v dot korzun at gmail dot com Summary:Unexpected behaviour with strpos() -Status: Open +Status: Not a bug Type: Bug Package:*Programming Data Structures Operating System: *Nix PHP Version:5.3.18 Block user comment: N Private report: N New Comment: The code actually gives this message first: PHP Warning: strpos() expects parameter 1 to be string, array given It's standard for PHP to behave like this for parameter parsing errors. E.g. all but a few of the str* functions are implemented using 'return' in this case. Only strrpos, strripos, strpbrk, (and substr_compare) use RETURN_FALSE. Previous Comments: [2012-10-24 19:09:02] aleksey dot v dot korzun at gmail dot com Description: Please review code snippet below, expected behaviour is that code within if statement will not be executed (since the value was not found). Test script: --- Expected result: It should not output 'fail' Actual result: -- Outputs fail -- Edit this bug report at https://bugs.php.net/bug.php?id=63348&edit=1
Bug #63348 [Nab]: Unexpected behaviour with strpos()
Edit report at https://bugs.php.net/bug.php?id=63348&edit=1 ID: 63348 User updated by:aleksey dot v dot korzun at gmail dot com Reported by:aleksey dot v dot korzun at gmail dot com Summary:Unexpected behaviour with strpos() Status: Not a bug Type: Bug Package:*Programming Data Structures Operating System: *Nix PHP Version:5.3.18 Block user comment: N Private report: N New Comment: I'm aware of the notice, but in my opinion that this should be handled within the function and return false .vs null as in no match was found. - $0.2 Previous Comments: [2012-10-24 23:15:20] s...@php.net The code actually gives this message first: PHP Warning: strpos() expects parameter 1 to be string, array given It's standard for PHP to behave like this for parameter parsing errors. E.g. all but a few of the str* functions are implemented using 'return' in this case. Only strrpos, strripos, strpbrk, (and substr_compare) use RETURN_FALSE. [2012-10-24 19:09:02] aleksey dot v dot korzun at gmail dot com Description: Please review code snippet below, expected behaviour is that code within if statement will not be executed (since the value was not found). Test script: --- Expected result: It should not output 'fail' Actual result: -- Outputs fail -- Edit this bug report at https://bugs.php.net/bug.php?id=63348&edit=1
[PHP-BUG] Bug #63352 [NEW]: Can't enable hostname validation when using curl stream wrappers
From: geissert Operating system: PHP version: 5.4.8 Package: cURL related Bug Type: Bug Bug description:Can't enable hostname validation when using curl stream wrappers Description: When PHP is built with --with-curlwrappers, the context option "curl_verify_ssl_host" sets curl's CURLOPT_SSL_VERIFYHOST option to 1, but there is no way to set it to 2. Given that the option is a boolean, it should probably be setting the VERIFYHOST value to 2. There is no way to validate that the certificate belongs to the host otherwise. This applies to the ftps and https stream wrappers. -- Edit bug report at https://bugs.php.net/bug.php?id=63352&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63352&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63352&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63352&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63352&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63352&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63352&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63352&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63352&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63352&r=support Expected behavior: https://bugs.php.net/fix.php?id=63352&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63352&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63352&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63352&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63352&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63352&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63352&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63352&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63352&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63352&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63352&r=mysqlcfg
Bug #63352 [Com]: Can't enable hostname validation when using curl stream wrappers
Edit report at https://bugs.php.net/bug.php?id=63352&edit=1 ID: 63352 Comment by: geiss...@php.net Reported by:geiss...@php.net Summary:Can't enable hostname validation when using curl stream wrappers Status: Open Type: Bug Package:cURL related PHP Version:5.4.8 Block user comment: N Private report: N New Comment: Of course this is a minor issue as the certificates store can't even be set, so this is just for the record. Previous Comments: [2012-10-25 00:54:16] geiss...@php.net Description: When PHP is built with --with-curlwrappers, the context option "curl_verify_ssl_host" sets curl's CURLOPT_SSL_VERIFYHOST option to 1, but there is no way to set it to 2. Given that the option is a boolean, it should probably be setting the VERIFYHOST value to 2. There is no way to validate that the certificate belongs to the host otherwise. This applies to the ftps and https stream wrappers. -- Edit this bug report at https://bugs.php.net/bug.php?id=63352&edit=1
Bug #63344 [Com]: pg_query_params() doesn't pass parts of strings past zero byte character
Edit report at https://bugs.php.net/bug.php?id=63344&edit=1 ID: 63344 Comment by: peter dot kehl at gmail dot com Reported by:peter dot kehl at gmail dot com Summary:pg_query_params() doesn't pass parts of strings past zero byte character Status: Assigned Type: Bug Package:PostgreSQL related Operating System: CentOS 6.2; possibly irrelevant PHP Version:5.4.8 Assigned To:yohgaki Block user comment: N Private report: N New Comment: OK, pg_query_params() works as defined by Postgres. Thank you. However, I suggest a change of Example #1 at http://www.php.net/serialize. That example saves a result of serialize() to an ODBC database. I have no way of testing whether that works with strings containing zero byte(s). Anyway, that example may lead people to save a result of serialize() using Postgres (or MSSQL mssql_query()), which fail. Please change that example to use base64_encode() and base64_decode(), and add a note that serialize() generates a string which may contain zero byte(s). Previous Comments: [2012-10-24 06:35:04] larue...@php.net The following patch has been added/updated: Patch Name: bug63344.patch Revision: 1351060504 URL: https://bugs.php.net/patch-display.php?bug=63344&patch=bug63344.patch&revision=1351060504 [2012-10-24 06:34:33] larue...@php.net according to http://www.postgresql.org/docs/8.0/static/libpq-exec.html the current PHP's wrapper of PQexecParams doesn't support binary data. a simple fix is attached [2012-10-24 04:39:53] peter dot kehl at gmail dot com Description: This may not be a code problem, but a documentation problem. At the top, this is similar to https://bugs.php.net/bug.php?id=45491&edit=2, but not the same. If the current behaviour is intended, then it should be documented at www.php.net/pg_query_params - because current documentation doesn't mention that it doesn't support zero bytes. Summary If I call pg_query_params( $connection, $sql_query_with_dollar_placeholders, $params ) with all three parameters, and $params is an array with at least 1 value which is a string, which contains 1 or more zero bye characters (in PHP it's chr(0) or "\0"), then that zero byte character(s) and anything right from it (in the same string) won't be passed to Postgres server. I've checked Postgres server logs, and the values come truncated just before the first zero byte character. That is probably due to Postgres using/treating strings like C language does, ended with a zero byte character. However, in PHP a string can contain one or multiple zero byte characters. This happens when e.g. using output of PHP's function serialize(). Side note I'm curious whether there is any way to set a Postgres varchar/text column to contain one or more zero byte characters. Following fails in pgAdmin (which uses UTF-8): INSERT INTO null_character_test(value) VALUES( E'First\0Second'); Environment: -- PHP server: CentOS 6.3 Linux localhost.localdomain 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Compiled PHP 5.4.8 ./configure --prefix=/usr/local/php --with-pgsql --with-apxs2=/usr/sbin/apxs --enable-mbstring /usr/local/php/bin/php -v PHP 5.4.8 (cli) (built: Oct 24 2012 14:49:11) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies Postgres server (and also a PHP server, where the same problem applies) CentOS 6.2 Linux pkehlcentos.racpnet.localhost.local 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6 19:48:22 GMT 2011 x86_64 x86_64 x86_64 GNU/Linux PostgreSQL 8.4.11 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3), 64-bit. /usr/local/php/bin/php -v PHP 5.4.4 (cli) (built: Aug 15 2012 14:07:53) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans Test script: --- CREATE TABLE null_character_test( value varchar(255) ); that should match 1 row Actual result: -- SELECT * FROM null_character_test WHERE value='Only the first part (this one) gets saved to DB.' --> that matches 1 row -- Edit this bug report at https://bugs.php.net/bug.php?id=63344&edit=1
Bug #53228 [Opn->Nab]: memory leak when throwing exception in custom handler in functions
Edit report at https://bugs.php.net/bug.php?id=53228&edit=1 ID: 53228 Updated by: ahar...@php.net Reported by:kgrecki at gmail dot com Summary:memory leak when throwing exception in custom handler in functions -Status: Open +Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Good explanation and catch. Closing Not A Bug. Previous Comments: [2012-10-24 10:13:06] jille at hexon dot cx This is not a bug. If you unset($e); you don't leak any memory. It is because exceptions include a backtrace, containing all the arguments given to the error handling closure. The fifth argument given is $context, an array containing all local variables, including the previous $e. [2010-11-04 17:14:07] uramihsayibok at gmail dot com unset($e)ing in the catch block plugs the hole - the previous value/exception in $e isn't being destroyed? [2010-11-02 18:48:12] kgrecki at gmail dot com Description: I encountered a similar issue to #25335 where custom error handler + exceptions leaks memory but only when try-catch block is in a function and looped through directly. I imagine there's some scope/GC issues here, and whether this is actual bug or limitation of PHP. Test script: --- https://bugs.php.net/bug.php?id=53228&edit=1
Req #63268 [Com]: Scalar Casting
Edit report at https://bugs.php.net/bug.php?id=63268&edit=1
ID: 63268
Comment by: xianrenb at gmail dot com
Reported by:klaussantana at gmail dot com
Summary:Scalar Casting
Status: Open
Type: Feature/Change Request
Package:Unknown/Other Function
Operating System: Any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I think there are scripts relying on the default behavior of scalar type
casting.
Changing the default behavior could break those scripts.
If one wants to do something similar, he could write and use his own
classes/methods instead of using scalar types and type casting.
Using custom classes/methods are much more flexible as classes could be
extended.
On the other hand, introducing the new feature would make debugging much more
difficult.
PHP should continue the OO way, but not return to the non-OO way.
I would strongly recommend not implementing this feature.
Previous Comments:
[2012-10-12 21:47:09] klaussantana at gmail dot com
And then something like this:
register_casting_behavior( 'object', 'string', '::__toString' );
register_casting_behavior( 'object', 'int', '::__toInt' );
$S = new String('Teste');
echo $S; // will call __toString() method within $S and return the value...
echo $S +1; // will call __toInt() method within $S and return the value...
Callbacks would work somehow like this:
* When you specify an array with 1st parameter as a class name string and 2nd
as constructor it will instantiate the object. Else it will invoke the static
method.
* When you specify an array with 1st parameter as an object and 2nd as any
method it will invoke that method within that object
* If the origin type is "object" and the callback is a string that starts with
"::" it will call the remaining callback string as a method in the object being
casted as the destination
type.
[2012-10-12 21:20:23] klaussantana at gmail dot com
Note that it'll be automatically chainable because the result of ->toLower() is
a
string and it will cast as an object...
And you'll can also do something like this:
echo 'My String'->toLower();
Just suggestions.. comment.
[2012-10-12 21:16:36] klaussantana at gmail dot com
Description:
It would be nice if we can control the casting behavior of any type to another.
Like a function like this:
register_casting_behavior( $from, $to, $callback_function );
So when you do this:
register_casting_behavior( 'int', 'bool', 'int2bool' );
$X = (bool) 1;
It will call int2bool( 1 ) and so...
Then
Test script:
---
register_casting_behavior( 'string', 'object', array( 'String', '__construct' )
);
class String
{
protected $value = null;
public function __construct( $String )
{
$this->value = $String;
return $this;
}
public function toLower()
{
return strtolower($this->value);
}
public function underline()
{
return "{$this->value}";
}
}
$S = 'My String';
echo $S->toLower()->underline();
// will output: my string
--
Edit this bug report at https://bugs.php.net/bug.php?id=63268&edit=1
Bug #63347 [Opn]: Different behavior of parameters processing
Edit report at https://bugs.php.net/bug.php?id=63347&edit=1
ID: 63347
Updated by: larue...@php.net
Reported by:naquad at gmail dot com
Summary:Different behavior of parameters processing
Status: Open
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.4.8
Block user comment: N
Private report: N
New Comment:
seems native prepare supporting doesn't supports multi-same-name params, it
will
faild in the params number checking
Previous Comments:
[2012-10-24 14:06:31] naquad at gmail dot com
Description:
PDO::ATTR_EMULATE_PREPARES changes behavior of parameter processing.
When it is enabled multiple occurrences of named parameter work as expected,
but
when it is disabled I get "Invalid parameter number" error.
Test script:
---
setAttribute(PDO::ATTR_EMULATE_PREPARES, false); /// remove this line
and scirpt works as expected
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$query = $pdo->prepare('select :x = :x');
$query->bindValue(':x', 1);
$query->execute();
$t = $query->fetch();
var_dump($t);
$query->closeCursor();
Expected result:
array(2) {
'\'1\' = \'1\'' =>
string(1) "1"
[0] =>
string(1) "1"
}
Actual result:
--
PDOException: SQLSTATE[HY093]: Invalid parameter number in
/srv/http/fucktube/app/test.php on line 7
Call Stack:
0.0002 230552 1. {main}() /srv/http/fucktube/app/test.php:0
0.0739 246416 2. PDOStatement->execute()
/srv/http/fucktube/app/test.php:7
--
Edit this bug report at https://bugs.php.net/bug.php?id=63347&edit=1
Bug #63349 [Fbk]: Segfault during GC
Edit report at https://bugs.php.net/bug.php?id=63349&edit=1 ID: 63349 Updated by: larue...@php.net Reported by:phpwnd at gmail dot com Summary:Segfault during GC Status: Feedback Type: Bug Package:Reproducible crash Operating System: Gentoo Linux PHP Version:5.4.8 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ This seems very similar to #63055, which was fixed a short time ago, could you please test with the sanpshot of 5.4? Previous Comments: [2012-10-24 23:00:25] s...@php.net Thanks for the report. Can you continue working on it and: - Upload a script that reproduces the problem when XDebug is not installed - Upload build & configuration information - Try with zend.enable_gc = Off [2012-10-24 20:48:11] phpwnd at gmail dot com Description: PHP 5.4.8 + XDebug 2.2.1, no other extensions I've been experiencing a few segfaults lately. They've been a bit hard to reproduce because so far I've only hit them when using PHP_CodeCoverage and only on specific revisions of my code (adding or removing a single statement such as "$a=1;" would keep it from happening.) I have gotten around rebuilding PHP with all the debug bells and whistles and the resulting backtrace (hopefully attached to this bug) indicates it's related to GC and/or PCRE. Adding a call to gc_collect_cycles() fixed it for me, at least for now. -- Edit this bug report at https://bugs.php.net/bug.php?id=63349&edit=1
[PHP-BUG] Req #63354 [NEW]: Display Format
From: p dot varga at lottery24 dot net Operating system: Linux Suse Server PHP version: 5.4.7RC1 Package: Variables related Bug Type: Feature/Change Request Bug description:Display Format Description: Hi! It would be nice when the format of the numbers could be more human readable. Example how it is now: Allowed memory size of 13000 bytes exhausted (tried to allocate 13361 bytes) Thank you! Peter Test script: --- Expected result: Suggestion: Allowed memory size of 130.000.000 bytes exhausted (tried to allocate 133.600.001 bytes) -- Edit bug report at https://bugs.php.net/bug.php?id=63354&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63354&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63354&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63354&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63354&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63354&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63354&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63354&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63354&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63354&r=support Expected behavior: https://bugs.php.net/fix.php?id=63354&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63354&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63354&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63354&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63354&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63354&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63354&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63354&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63354&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63354&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63354&r=mysqlcfg
Req #63354 [Opn->Wfx]: Display Format
Edit report at https://bugs.php.net/bug.php?id=63354&edit=1 ID: 63354 Updated by: ahar...@php.net Reported by:p dot varga at lottery24 dot net Summary:Display Format -Status: Open +Status: Wont fix Type: Feature/Change Request Package:Variables related Operating System: Linux Suse Server PHP Version:5.4.7RC1 Block user comment: N Private report: N New Comment: Integer to string conversion in PHP is fundamental behaviour â we couldn't change this without a massive backward compatibility break (not to mention the additional problem of deciding which of the at least four schemes I know of for digit grouping would be used). Plus, number_format() already exists for the common cases. Marking Won't Fix. Previous Comments: [2012-10-25 05:54:05] p dot varga at lottery24 dot net Description: Hi! It would be nice when the format of the numbers could be more human readable. Example how it is now: Allowed memory size of 13000 bytes exhausted (tried to allocate 13361 bytes) Thank you! Peter Test script: --- Expected result: Suggestion: Allowed memory size of 130.000.000 bytes exhausted (tried to allocate 133.600.001 bytes) -- Edit this bug report at https://bugs.php.net/bug.php?id=63354&edit=1
