#45968 [NEW]: urlencode with a safe paremeter
From: info at marcel-schlesinger dot de
Operating system:
PHP version: 6CVS-2008-09-02 (snap)
PHP Bug Type: URL related
Bug description: urlencode with a safe paremeter
Description:
I looked myself and determined that the RFC3986 is very spongelike.
Compared with other programming languages I noticed that everyone
differently converts the RFC.
In Python there is a nice feature, that you can tell wich chars have to be
safe urllib.quote(s, safe='~'). All chars except this one in the safe
parameter are escaped.
With PHP you could do this only with a search replace function which
isn't very nice.
So i want to suggest, to add likewise one more parameter to the urlencode
function.
Expected result:
echo urlencode(Test str \'.-/, array('\'', ''));
output:
Test+str+'%2E%2D%2F
==
echo rawurlencode(Test str \'.-/, array('\'', ''));
output:
Test%20str%20'%2E%2D%2F
Actual result:
--
echo urlencode(Test str \'.-/);
output:
Test+str+%22%27.-%2F
==
echo rawurlencode(Test str \'.-/);
output:
Test%20str%20%22%27.-%2F
--
Edit bug report at http://bugs.php.net/?id=45968edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45968r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45968r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45968r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45968r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45968r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45968r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45968r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45968r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45968r=support
Expected behavior:http://bugs.php.net/fix.php?id=45968r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45968r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45968r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45968r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45968r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45968r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45968r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45968r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45968r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45968r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45968r=mysqlcfg
#45954 [Bgs]: memory leak with unset(array)
ID: 45954
Updated by: [EMAIL PROTECTED]
Reported By: mail at milianw dot de
Status: Bogus
Bug Type: Performance problem
Operating System: *
PHP Version: 5.2.6
New Comment:
The internal memory manager is keeping tabs of the memory and will
reuse
it again if there is a memory allocation that it can fit in the block.
You can use valgrind and see that the memory is in fact free'd when the
request ends.
Previous Comments:
[2008-09-01 17:48:18] mail at milianw dot de
So there is simply no way at all to delete / free / unset variables in
PHP? But why does it work perfectly (i.e. like I imagine it should) when
I unset a string, even a very large one? That one frees the memory
instantaneously. But not so for arrays.
I simply cannot see the reasoning behind this. When a programmer calls
unset he seems to know that this very variable can be freed, or not? So
why do we need to wait for a GC to step in and do the actual cleanup? As
far as my limited knowledge goes manual delete/free is compatible with a
GC, or not? Or is it only possible to free simple strings, ints etc. but
not arrays?
Take this code:
?php
function foo() {
$string = '';
for ($i = 0; $i 1000; ++$i) {
$string .= 'asdfasdfasdf';
}
}
$i = 0;
echo setup:\t.memory_get_usage().\n;
for (; $i 10; ++$i) {
foo();
echo run $i:\t.memory_get_usage().\n;
}
Output:
setup: 65524
run 0: 66108
run 1: 66184
run 2: 66248
and constant thereafter.
If I know change the code slightly:
?php
function foo() {
$array = '';
for ($i = 0; $i 1000; ++$i) {
$array[] = 'asdfasdfasdf';
}
}
$i = 0;
echo setup:\t.memory_get_usage().\n;
for (; $i 10; ++$i) {
foo();
echo run $i:\t.memory_get_usage().\n;
}
The output becomes:
setup: 65364
run 0: 130356
run 1: 130364
run 2: 130384
run 3: 130344
and thereafter either that value or 130364
Ok - it's not a leak per se, yet I wonder: A function I called which
setup an array should free that memory (or should get its memory freed)
after stepping out of it's scope, no? Just like it does with strings...
Also: I can append the following code to the last snippet to verify
that the memory is _never_ freed:
while (true) {
echo memory_get_usage().\n;
}
I actually altered it a bit to break when the memory consumption
changes, and could potentially wait for hours.
So is this really no bug? Could it not be that e.g. some internal hash
pointers are left behind without getting deleted?
[2008-08-31 00:28:28] [EMAIL PROTECTED]
unset() is not free(). PHP uses memory manager that does the actual
garbage cleanup during request shutdown.
[2008-08-30 16:12:43] mail at milianw dot de
Description:
When you setup an array and unset() it afterwards, not all memory is
freed. I've run the code below on various PHP versions, including 5.2.6
(via Xampp) on Linux and Windows and always get output like:
startup:64296
array setup:13789672
unsetted array: 129284
The end value is more than twice as large as the start value.
Also interestingly is that low values in the for loop [e.g. for($i = 0;
$i 1; ++$i)] result in outputs like
startup: 64296
array setup:64864
unsetted array: 64864
Could it be that unset() relies on the Garbage Collector to do the work
instead of really destroying the variables? But then I find it strange
that even if I put a sleep(10) after the unset I still get the same
outputs for unsetted array.
Reproduce code:
---
?php
echo startup:.memory_get_usage().\n;
$array = array();
for ($i = 0; $i 10; ++$i) {
$array[] = 'foobar';
}
echo array setup:.memory_get_usage().\n;
unset($array);
echo unsetted array: .memory_get_usage().\n;
Expected result:
My expectations would be that the value reported at the end would be
nearly equal to the startup value.
Additionally a call to unset() should (imo) not rely on the GC but do
the deleting itself instantaneously.
NOTE: I've seen http://bugs.php.net/bug.php?id=41713 which tells a
similar story, but it should be fixed as far as the bug report tells.
Additionally it was Windows only yet I spotted the described behaviour
first on a Linux machine.
--
Edit this bug report at http://bugs.php.net/?id=45954edit=1
#45970 [NEW]: Weird rounding behaviour
From: jan dot vernieuwe at webline dot be Operating system: FreeBSD PHP version: 5.2.6 PHP Bug Type: Math related Bug description: Weird rounding behaviour Description: Rounding a calculated float gives bad results, rounding it as a string works as intended. Reproduce code: --- ?php echo pre; $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 /pre; ? 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 bug report at http://bugs.php.net/?id=45970edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45970r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45970r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45970r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45970r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45970r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45970r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45970r=needscript Try newer version:http://bugs.php.net/fix.php?id=45970r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45970r=support Expected behavior:http://bugs.php.net/fix.php?id=45970r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45970r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45970r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45970r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45970r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45970r=dst IIS Stability:http://bugs.php.net/fix.php?id=45970r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45970r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45970r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45970r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45970r=mysqlcfg
#45970 [Opn-Bgs]: Weird rounding behaviour
ID: 45970 Updated by: [EMAIL PROTECTED] Reported By: jan dot vernieuwe at webline dot be -Status: Open +Status: Bogus Bug Type: Math related Operating System: FreeBSD 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. Previous Comments: [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: --- ?php echo pre; $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 /pre; ? 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=45970edit=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: --- ?php echo pre; $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 /pre; ? 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=45970edit=1
#43958 [Opn-Csd]: class name added into the error message
ID: 43958 Updated by: [EMAIL PROTECTED] Reported By: sv4php at fmethod dot com -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 5.2.5 -Assigned To: +Assigned To: dmitry 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-02-02 08:37:48] sv4php at fmethod dot com 'Exactly why it shouldn't print the class in which this happens?' Four solid reasons: 1. Because running a method in the class is not the same as defining a method for the class. 2. Replace 'include $p' with 'file_get_contents($p)' above, it does NOT print the class (and it shouldn't). 3. If you have html_errors on, it prints a link that directs you to the manual for method include in class MyClass, which doesn't exist. 4. For us wild experimenters, makes re-routing errors in error handlers less trivial, since the output is wrong... [2008-02-01 22:32:29] [EMAIL PROTECTED] Exactly why it shouldn't print the class in which this happens? [2008-01-31 00:49:31] [EMAIL PROTECTED] My suggestion: http://ecl.zoone.com.br/etc/patches/bug43958.diff [2008-01-29 11:30:43] kissifrot at gmail dot com Reproduces with PHP 5.2.5 on Windows Vista too PHP Version 5.2.5; Windows NT 6.0 build 6000; Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies This happens with require function too [2008-01-29 08:50:45] jck_true at hotmail dot com PHP Version 5.2.3 Build date: May 31 2007 09:36:39 Windows XP Profesional SP2 Reproduced 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/43958 -- Edit this bug report at http://bugs.php.net/?id=43958edit=1
#44428 [Opn-Bgs]: file and line missing in debug_backtrace() output
ID: 44428
Updated by: [EMAIL PROTECTED]
Reported By: thuejk at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.2.5
-Assigned To:
+Assigned To: dmitry
New Comment:
The debug backtrace shows filename and lineno of calling script. In
case function is called from inside internal function (may be as
callback) no filename and lineno may be set.
Previous Comments:
[2008-03-30 17:56:28] php at xuefeng dot org
Index: zend_builtin_functions.c
===
RCS file: /repository/ZendEngine2/zend_builtin_functions.c,v
retrieving revision 1.277.2.12.2.25.2.14
diff -u -r1.277.2.12.2.25.2.14 zend_builtin_functions.c
--- zend_builtin_functions.c10 Mar 2008 22:02:41
- 1.277.2.12.2.25.2.14
+++ zend_builtin_functions.c30 Mar 2008 17:54:29 -
@@ -2000,6 +2000,19 @@
} else if (ptr-function_state.function-common.scope) {
add_assoc_string_ex(stack_frame, class, sizeof(class),
ptr-function_state.function-common.scope-name, 1);
add_assoc_string_ex(stack_frame, type, sizeof(type), ::,
1);
+
+ } else if (ptr-function_state.function-common.type ==
ZEND_USER_FUNCTION) {
+
+ if (ptr-function_state.function-op_array.filename) {
+ add_assoc_string_ex(stack_frame, file,
sizeof(file),
+
ptr-function_state.function-op_array.filename, 1
+ );
+ }
+ if (ptr-function_state.function-op_array.opcodes) {
+ add_assoc_long_ex(stack_frame, line, sizeof(line),
+
ptr-function_state.function-op_array.opcodes-lineno
+ );
+ }
}
if ((! ptr-opline) || ((ptr-opline-opcode ==
ZEND_DO_FCALL_BY_NAME) || (ptr-opline-opcode == ZEND_DO_FCALL))) {
[2008-03-13 12:03:59] thuejk at gmail dot com
Description:
In all cases (but the one below one), file and line indexes are
defined in each frame of the output of debug_backtrace.
But when using call_user_function() or call_user_function_array, file
and line is not defined for one of the frames.
It would be nice if I could count on file and line always being defined
when using the output of debug_backtrace, thereby avoiding code for
special cases.
For the missing file and line in the example code below, when calling
f() inside call_user_function(), I suggest using the file and line of
the call_user_function() call.
See also bug 38047 and 24405.
Reproduce code:
---
?php
error_reporting(E_ALL | E_STRICT);
function f() {
$a = $b;
var_dump(debug_backtrace());
}
//The backtrace generated here will not have file and line defined
call_user_func(f, Array());
//The backtrace generated here will have file and line defined.
f();
?
Expected result:
The frame with index 0 of the first debug_backtrace_call should contain
indexes file = test.php and line = 6
Actual result:
--
array(2) {
[0]=
array(2) {
[function]=
string(1) f
[args]=
array(1) {
[0]=
array(0) {
}
}
}
[1]=
array(4) {
[file]=
string(18) /home/tjk/test.php
[line]=
int(6)
[function]=
string(14) call_user_func
[args]=
array(2) {
[0]=
string(1) f
[1]=
array(0) {
}
}
}
}
array(1) {
[0]=
array(4) {
[file]=
string(18) /home/tjk/test.php
[line]=
int(8)
[function]=
string(1) f
[args]=
array(0) {
}
}
}
--
Edit this bug report at http://bugs.php.net/?id=44428edit=1
#45971 [NEW]: SimpleXMLElement does not overload properly
From: dennis at d23 dot nl
Operating system: Fedora 8/Windows
PHP version: 5.2.6
PHP Bug Type: SimpleXML related
Bug description: SimpleXMLElement does not overload properly
Description:
When extending SimpleXMLElement the __get() and __set() methods of the
extending class do not get invoked.
__call however works as expected.
Reproduce code:
---
?php
class TestSimpleXMLElement extends SimpleXMLElement {
function __set($name, $value) { echo __set $name\n; }
function __get($name) { echo __get $name\n; }
function __call($name, $parameters) { echo __call $name\n; }
}
$element = new TestSimpleXMLElement('root/');
// __set
$element-child1 = 1;
// __get
$element-child2;
// __call
$element-method();
?
Expected result:
__set child1
__get child2
__call method
Actual result:
--
__call method
--
Edit bug report at http://bugs.php.net/?id=45971edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45971r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45971r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45971r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45971r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45971r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45971r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45971r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45971r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45971r=support
Expected behavior:http://bugs.php.net/fix.php?id=45971r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45971r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45971r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45971r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45971r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45971r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45971r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45971r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45971r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45971r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45971r=mysqlcfg
#45037 [Com]: wddx_add_vars() does not convert variable names to UTF8
ID: 45037
Comment by: JeanLuc dot TRIPLET at yahoo dot fr
Reported By: JeanLuc dot TRIPLET at yahoo dot fr
Status: Open
Bug Type: WDDX related
Operating System: Windows
PHP Version: 5.2.6
New Comment:
Modifying wddx.c as below solves the problem (php_wddx_serialize_var
also encode parameter names in addition to parameter values) :
Original wddx.c :
void php_wddx_serialize_var(wddx_packet *packet, zval *var, char *name,
int name
_len TSRMLS_DC)
{
char *tmp_buf;
char *name_esc;
int name_esc_len;
HashTable *ht;
if (name) {
name_esc = php_escape_html_entities(name, name_len,
name_esc_len, 0, ENT_QUOTES, NULL TSRMLS_CC);
tmp_buf = emalloc(name_esc_len + sizeof(WDDX_VAR_S));
snprintf(tmp_buf, name_esc_len + sizeof(WDDX_VAR_S),
WDDX_VAR_S, name_esc);
php_wddx_add_chunk(packet, tmp_buf);
efree(tmp_buf);
efree(name_esc);
}
Mofified wddx.c :
void php_wddx_serialize_var(wddx_packet *packet, zval *var, char *name,
int name
_len TSRMLS_DC)
{
char *tmp_buf;
char *enc;
char *name_esc;
int name_esc_len;
int enc_len;
HashTable *ht;
if (name) {
name_esc = php_escape_html_entities(name, name_len,
name_esc_len, 0, ENT_QUOTES, NULL TSRMLS_CC);
enc = xml_utf8_encode(name_esc, name_esc_len, enc_len,
ISO-8859-1);
tmp_buf = emalloc(enc_len + sizeof(WDDX_VAR_S));
snprintf(tmp_buf, enc_len + sizeof(WDDX_VAR_S),
WDDX_VAR_S, enc);
php_wddx_add_chunk(packet, tmp_buf);
efree(tmp_buf);
efree(name_esc);
efree(enc);
Could you, please, include some modification like this one in future
versions.
Thanks in advance.
Previous Comments:
[2008-05-19 10:13:11] JeanLuc dot TRIPLET at yahoo dot fr
Description:
wddx_add_vars() correctly converts values to UTF-8, but doesn't convert
var names to UTF-8, so wddx_deserialize() return an empty array as XML
packet contains var names with accent.
below is a script showing that string values are converted to UTF-8 by
wddx_add_vars, but var names are not converted. It also show that
wddx_deserialize() works fine when input packet contains UTF_8 encoded
var names manually, but doesn't work when var names are let accentuated
by wddx_add_vars().
Could you please, modify wddx_add_vars, to UTF_8 encode var names as
already done for string values ?
Thank for your help.
Reproduce code:
---
?php
// If varname is ascii, unserialize is OK //
$packet_id = wddx_packet_start(PHP);
$varname = value é;
wddx_add_vars($packet_id,varname);
$packet = wddx_packet_end($packet_id);
var_dump ($packet);
echo \n\n;
$result = wddx_deserialize($packet);
var_dump ($result);
// If varname is non_ascii, unserialize return array(0) {} //
$packet_id = wddx_packet_start(PHP);
$varnameé = value é;
wddx_add_vars($packet_id,varnameé);
$packet = wddx_packet_end($packet_id);
var_dump ($packet);
$result = wddx_deserialize($packet);
var_dump ($result);
// If packet contains non_ascii UTF-8 encoded varname, unserialize is
OK //
$packet = wddxPacket
version='1.0'headercommentPHP/comment/headerdatastructvar
name='varnameé'stringvalue
é/string/var/struct/data/wddxPacket;
var_dump ($packet);
$result = wddx_deserialize($packet);
var_dump ($result);
?
Expected result:
string(159) value é
array(1) { [varname]= string(7) value é }
string(160) value é
array(1) { [varnameé]= string(7) value é }
string(161) value é
array(1) { [varnameé]= string(7) value é }
Actual result:
--
string(159) value é
array(1) { [varname]= string(7) value é }
string(160) value é
array(0) { }
string(161) value é
array(1) { [varnameé]= string(7) value é }
--
Edit this bug report at http://bugs.php.net/?id=45037edit=1
#45972 [NEW]: Date escaping goes incorrectly
From: woeterman at gmail dot com Operating system: Linux Debian PHP version: 5.2.6 PHP Bug Type: Date/time related Bug description: Date escaping goes incorrectly Description: When escaping with date(\t), it shows up as nothing instead of 't'. It seems to work fine with other characters, such as \a Reproduce code: --- ?php echo 1: . date(jS \of F Y H:i:s). br /; echo 2: . date(jS \of F Y at H:i:s). br /; echo 3: . date(jS \of F Y \at H:i:s). br /; echo 4: . date(jS \of F Y \a\t H:i:s). br /; echo 5: . date(jS \of F Y \t H:i:s). br /; ? Expected result: 1: 2nd of September 2008 13:36:57 2: 2nd of September 2008 pm30 13:36:57 3: 2nd of September 2008 a30 13:36:57 4: 2nd of September 2008 at 13:36:57 5: 2nd of September 2008 t 13:36:57 Actual result: -- 1: 2nd of September 2008 13:36:57 2: 2nd of September 2008 pm30 13:36:57 3: 2nd of September 2008 a30 13:36:57 4: 2nd of September 2008 a 13:36:57 5: 2nd of September 2008 13:36:57 -- Edit bug report at http://bugs.php.net/?id=45972edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45972r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45972r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45972r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45972r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45972r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45972r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45972r=needscript Try newer version:http://bugs.php.net/fix.php?id=45972r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45972r=support Expected behavior:http://bugs.php.net/fix.php?id=45972r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45972r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45972r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45972r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45972r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45972r=dst IIS Stability:http://bugs.php.net/fix.php?id=45972r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45972r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45972r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45972r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45972r=mysqlcfg
#45972 [Opn-Bgs]: Date escaping goes incorrectly
ID: 45972 Updated by: [EMAIL PROTECTED] Reported By: woeterman at gmail dot com -Status: Open +Status: Bogus Bug Type: Date/time related Operating System: Linux Debian PHP Version: 5.2.6 New Comment: That's because normal string escape rules still apply, and \t is the tab character. Previous Comments: [2008-09-02 11:37:42] woeterman at gmail dot com Description: When escaping with date(\t), it shows up as nothing instead of 't'. It seems to work fine with other characters, such as \a Reproduce code: --- ?php echo 1: . date(jS \of F Y H:i:s). br /; echo 2: . date(jS \of F Y at H:i:s). br /; echo 3: . date(jS \of F Y \at H:i:s). br /; echo 4: . date(jS \of F Y \a\t H:i:s). br /; echo 5: . date(jS \of F Y \t H:i:s). br /; ? Expected result: 1: 2nd of September 2008 13:36:57 2: 2nd of September 2008 pm30 13:36:57 3: 2nd of September 2008 a30 13:36:57 4: 2nd of September 2008 at 13:36:57 5: 2nd of September 2008 t 13:36:57 Actual result: -- 1: 2nd of September 2008 13:36:57 2: 2nd of September 2008 pm30 13:36:57 3: 2nd of September 2008 a30 13:36:57 4: 2nd of September 2008 a 13:36:57 5: 2nd of September 2008 13:36:57 -- Edit this bug report at http://bugs.php.net/?id=45972edit=1
#45973 [NEW]: segfault when setting include_path to concat. of non-defined ${include_path}
From: olivier dot berger at it-sudparis dot eu
Operating system: Debian lenny
PHP version: 5.2.6
PHP Bug Type: Reproducible crash
Bug description: segfault when setting include_path to concat. of non-defined
${include_path}
Description:
If include_path wasn't set already, setting it to some concatenation of
${include_path} causes a segfault.
Seems different from #37002, AFAICT
More details in Debian bug :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497453
Reproduce code:
---
For instance, if /etc/php5/apache2/php.ini doesn't contain any
include_path definition, like is by default in Debian :
; UNIX: /path1:/path2
;include_path = .:/usr/share/php
then setting the following in for instance /etc/php5/conf.d/zend.ini :
[Zend]
include_path = ${include_path} :/usr/share/php/libzend-framework-php
leads to segmentation fault.
Expected result:
I guess referencing variables no yet explicitely set, but having default
values should return their default value.
Uncommenting the default include_path in /etc/php5/apache2/php.ini allows
it to work.
Actual result:
--
Apache segmentation fault
--
Edit bug report at http://bugs.php.net/?id=45973edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45973r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45973r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45973r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45973r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45973r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45973r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45973r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45973r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45973r=support
Expected behavior:http://bugs.php.net/fix.php?id=45973r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45973r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45973r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45973r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45973r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45973r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45973r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45973r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45973r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45973r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45973r=mysqlcfg
#45860 [Ver-Csd]: header() function fails to correctly replace all Status lines
ID: 45860 Updated by: [EMAIL PROTECTED] Reported By: overlordq at gmail dot com -Status: Verified +Status: Closed Bug Type: CGI related Operating System: * PHP Version: 5.2CVS, 5.3CVS, 6CVS (2008-08-19) -Assigned To: +Assigned To: dmitry 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-08-19 08:40:04] overlordq at gmail dot com Description: From the documentation: --- There are two special-case header calls. The first is a header that starts with the string HTTP/ (case is not significant), which will be used to figure out the HTTP status code to send. --- and --- The optional replace parameter indicates whether the header should replace a previous similar header, or add a second header of the same type. By default it will replace [...] --- But as can be seen below, header fails to replace headers in all cases. Reproduce code: --- http://toolserver.org/~overlordq/results.txt Actual result: -- As can be seen in the code linked above, header only truly replaces a similar header in the case if the Status is 200, for every other status code (that I've tested) PHP will output a duplicate header which does not conform to CGI spec. -- Edit this bug report at http://bugs.php.net/?id=45860edit=1
#45895 [Opn-Csd]: Exception in set_error_handler() messes up backtrace args
ID: 45895
Updated by: [EMAIL PROTECTED]
Reported By: jmcgraw1 at gmail dot com
-Status: Open
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: CentOS
PHP Version: 5.2.6
-Assigned To:
+Assigned To: dmitry
New Comment:
The bug is already fixed in CVS HEAD and PHP_5_3, however it is not
possible to fix it in PHP_5_2 branch without binary compatibility break.
Previous Comments:
[2008-08-27 13:13:14] jmcgraw1 at gmail dot com
PHP 5.2.6 (cli) (built: May 8 2008 16:50:48)
Output:
array(3) {
[0]=
array(4) {
[file]=
string(26) /home/jmcgraw/test_old.php
[line]=
int(10)
[function]=
string(13) handle_errors
[args]=
array(0) {
}
}
[1]=
array(4) {
[file]=
string(26) /home/jmcgraw/test_old.php
[line]=
int(14)
[function]=
string(1) A
[args]=
array(1) {
[0]=
string(6) foobar
}
}
[2]=
array(3) {
[file]=
string(26) /home/jmcgraw/test_old.php
[line]=
int(18)
[function]=
string(1) B
}
}
PHP 5.2.7-dev (cli) (built: Aug 27 2008 12:47:06)
Output:
array(3) {
[0]=
array(4) {
[file]=
string(22) /home/jmcgraw/test_new.php
[line]=
int(10)
[function]=
string(13) handle_errors
[args]=
array(0) {
}
}
[1]=
array(4) {
[file]=
string(22) /home/jmcgraw/test_new.php
[line]=
int(14)
[function]=
string(1) A
[args]=
array(1) {
[0]=
string(6) foobar
}
}
[2]=
array(3) {
[file]=
string(22) /home/jmcgraw/test_new.php
[line]=
int(18)
[function]=
string(1) B
}
}
Result:
Latest snapshot does NOT solve problem.
[2008-08-26 22:36:18] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2008-08-22 21:52:57] jmcgraw1 at gmail dot com
Description:
Throwing an exception within set_error_handler() produces an exception
which produces a messed up backtrace. Each entry within the backtrace
contains the 'args' for the previous call, with the most immediate entry
missing its 'args'. In the case of my example below the string 'foobar'
should be in the array 'args' for the call to B(), not A().
Reproduce code:
---
function handle_errors() {
throw new ErrorException();
}
set_error_handler('handle_errors', E_ALL);
function A() {
$foo-bar; // Purposely cause error
}
function B($c) {
A();
}
try {
B('foobar');
} catch (Exception $e) {
var_dump($e-getTrace());
}
Expected result:
array(3) {
[0]=
array(4) {
[file]=
string(42) /home/public/pdt/framework/html/error.php
[line]=
int(10)
[function]=
string(13) handle_errors
[args]=
array(0) {
}
}
[1]=
array(4) {
[file]=
string(42) /home/public/pdt/framework/html/error.php
[line]=
int(14)
[function]=
string(1) A
}
[2]=
array(3) {
[file]=
string(42) /home/public/pdt/framework/html/error.php
[line]=
int(18)
[function]=
string(1) B
[args]=
array(1) {
[0]=
string(6) foobar
}
}
}
Actual result:
--
array(3) {
[0]=
array(4) {
[file]=
string(42) /home/public/pdt/framework/html/error.php
[line]=
int(10)
[function]=
string(13) handle_errors
[args]=
array(0) {
}
}
[1]=
array(4) {
[file]=
string(42) /home/public/pdt/framework/html/error.php
[line]=
int(14)
[function]=
string(1) A
[args]=
array(1) {
[0]=
string(6) foobar
}
}
[2]=
array(3) {
[file]=
string(42) /home/public/pdt/framework/html/error.php
[line]=
int(18)
[function]=
string(1) B
}
}
--
Edit this bug report at http://bugs.php.net/?id=45895edit=1
#45327 [Opn-Fbk]: [PATCH] memory leak if offsetGet throws exception (PHP_5_2 branch only!)
ID: 45327
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: linux 64bit
PHP Version: 5.2CVS-2008-06-21
New Comment:
ext/phar is not a part of PHP_5_2 branch, and I don't see any leaks in
PHP_5_3. Do you still have this leak? Could you provide a script that
causes leak on PHP_5_2 (without ext/phar) or PHP_5_3 (with phar).
Previous Comments:
[2008-06-21 17:36:19] [EMAIL PROTECTED]
Description:
ext/phar's test phar_offset_get_error.phpt fails with leaked memory in
zend_execute_API.c:1023, which is where retval is allocated. It turns
out that if offsetGet() throws an exception, zend_std_read_dimension()
does not free the return zval, and it leaks. This only affects PHP 5.2.
The patch to fix is at http://pear.php.net/~greg/fix_leak.patch.txt and
is pasted below
Reproduce code:
---
Index: Zend/zend_object_handlers.c
===
RCS file: /repository/ZendEngine2/zend_object_handlers.c,v
retrieving revision 1.135.2.6.2.28
diff -u -r1.135.2.6.2.28 zend_object_handlers.c
--- Zend/zend_object_handlers.c 21 Feb 2008 13:55:22 -
1.135.2.6.2.28
+++ Zend/zend_object_handlers.c 21 Jun 2008 17:33:18 -
@@ -469,6 +469,10 @@
return 0;
}
+ if (EG(exception)) {
+ zval_ptr_dtor(retval);
+ return 0;
+ }
/* Undo PZVAL_LOCK() */
retval-refcount--;
--
Edit this bug report at http://bugs.php.net/?id=45327edit=1
#45125 [Opn-Bgs]: FastCGI: option -C chdir to the script's directory doesn't work
ID: 45125
Updated by: [EMAIL PROTECTED]
Reported By: florent at guiliani dot fr
-Status: Open
+Status: Bogus
Bug Type: CGI related
Operating System: GNU/Linux Ubuntu
PHP Version: 5.2.6
-Assigned To:
+Assigned To: dmitry
New Comment:
At first note that -C means DO NOT chdir to the script's directory (it
is not clear from the report).
-C option has effect only for command-line usage by design.
In case PHP supports it in FastCGI mode (as requested), we will allow
incompatible behavior between FastCGI and other SAPIs, whish always do
chdir to script's directory. So scripts, which written in assumption
that this option work, won't work with other SAPIs. Also with this
option enabled, any chdir() in PHP script may break all the following
requests, because of invalid CWD expectation.
In your example (/usr/bin/php5-cgi -C -b 9876) -C just doesn't have
effect.
Previous Comments:
[2008-05-29 10:14:04] florent at guiliani dot fr
Description:
The option -C chdir to the script's directory doesn't work when using
PHP as FASTCGI server.
Due to this issue a first request will work and a second identical
request will return no input file specified
Reproduce code:
---
$ strace -o strace.log /usr/bin/php5-cgi -C -b 9876
(run 2 identical requests)
$ grep chdir\|index.php strace.log
lstat64(/home/flgu/tmp/websvn/index.php, {st_mode=S_IFREG|0644,
st_size=1656, ...}) = 0
open(/home/flgu/tmp/websvn/index.php, O_RDONLY|O_LARGEFILE) = 7
chdir(/home/flgu/tmp/websvn) = 0
open(/home/flgu/tmp/websvn/websvn/index.php, O_RDONLY|O_LARGEFILE) =
-1 ENOENT (No such file or directory)
$
Note the double websvn/websvn in the second open.
You can use this cgi to test it (adapt it with your own path):
#!/bin/bash
export SCRIPT_FILENAME=${REQUEST_URI/\/~flgu\/fast.cgi\//}
/home/flgu/tmp/fcgi-2.4.0/cgi-fcgi/cgi-fcgi -bind -connect
localhost:9876
Expected result:
No chdir called and all request work
Actual result:
--
chdir called and only first request work
--
Edit this bug report at http://bugs.php.net/?id=45125edit=1
#45974 [NEW]: parse_ini_file strange work with some char combination
From: mete0 at gtn dot ru
Operating system: OpenBSD current
PHP version: 5.2.6
PHP Bug Type: *Directory/Filesystem functions
Bug description: parse_ini_file strange work with some char combination
Description:
Function `parse_ini_file()` work strange with this char combination `!`
as value for parameters, all chars after `!` will be skipped.
Example:
file `config.ini`
[test]
one = work fine
two = !work fine too
three = !does not work
Reproduce code:
---
?php
$cfg = parse_ini_file('config.in');
print_r($cfg);
?
Expected result:
Array ( [one] = work fine [two] = !work fine too [three] =
--
Edit bug report at http://bugs.php.net/?id=45974edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45974r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45974r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45974r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45974r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45974r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45974r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45974r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45974r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45974r=support
Expected behavior:http://bugs.php.net/fix.php?id=45974r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45974r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45974r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45974r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45974r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45974r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45974r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45974r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45974r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45974r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45974r=mysqlcfg
#45975 [NEW]: SoapClient tries to convert stdClass into string
From: v0idnull at psikon dot com
Operating system: Ubuntu
PHP version: 5.2.6
PHP Bug Type: SOAP related
Bug description: SoapClient tries to convert stdClass into string
Description:
Call a webservice method. Method returns one value, a string. SoapClient
internally tries to convert an instance of stdClass into a string before
trying to return the value, thus nothing works.
Reproduce code:
---
$packet = array('sessionToken' = $this-searchAuth, 'userId' = '-1',
'expirationDate' = '2008-11-01');
// $this-soap is instance of SoapClient
$results = $this-soap-__soapCall('GenerateToken',array($packet));
var_dump($results);
Webservice returns:
?xml version=1.0 encoding=utf-8?
soap12:Envelope xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap12=http://www.w3.org/2003/05/soap-envelope;
soap12:Body
GenerateTokenResponse xmlns=~/WebServices/
GenerateTokenResultstring/GenerateTokenResult
/GenerateTokenResponse
/soap12:Body
/soap12:Envelope
Expected result:
A string containing the value of GeneratTokenResult
OR
class stdClass
{
public $GenerateTokenResult = 'someKindOfToken';
}
Actual result:
--
Catchable fatal error: Object of class stdClass could not be converted to
string
error is thrown on the line with __soapCall().
--
Edit bug report at http://bugs.php.net/?id=45975edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45975r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45975r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45975r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45975r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45975r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45975r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45975r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45975r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45975r=support
Expected behavior:http://bugs.php.net/fix.php?id=45975r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45975r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45975r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45975r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45975r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45975r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45975r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45975r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45975r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45975r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45975r=mysqlcfg
#45974 [Opn]: parse_ini_file strange work with some char combination
ID: 45974
User updated by: mete0 at gtn dot ru
Reported By: mete0 at gtn dot ru
Status: Open
Bug Type: *Directory/Filesystem functions
Operating System: OpenBSD current
PHP Version: 5.2.6
New Comment:
Small typo in reproduce code, file name must be `config.ini` not
`config.in`
Previous Comments:
[2008-09-02 16:01:50] mete0 at gtn dot ru
Description:
Function `parse_ini_file()` work strange with this char combination
`!` as value for parameters, all chars after `!` will be skipped.
Example:
file `config.ini`
[test]
one = work fine
two = !work fine too
three = !does not work
Reproduce code:
---
?php
$cfg = parse_ini_file('config.in');
print_r($cfg);
?
Expected result:
Array ( [one] = work fine [two] = !work fine too [three] =
--
Edit this bug report at http://bugs.php.net/?id=45974edit=1
#45327 [Fbk-Opn]: [PATCH] memory leak if offsetGet throws exception (PHP_5_2 branch only!)
ID: 45327
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: linux 64bit
PHP Version: 5.2CVS-2008-06-21
Assigned To: dmitry
New Comment:
yes, to reproduce, cp ext/phar from PHP_5_3 into PHP_5_2 and run the
test I described
Previous Comments:
[2008-09-02 13:44:20] [EMAIL PROTECTED]
ext/phar is not a part of PHP_5_2 branch, and I don't see any leaks in
PHP_5_3. Do you still have this leak? Could you provide a script that
causes leak on PHP_5_2 (without ext/phar) or PHP_5_3 (with phar).
[2008-06-21 17:36:19] [EMAIL PROTECTED]
Description:
ext/phar's test phar_offset_get_error.phpt fails with leaked memory in
zend_execute_API.c:1023, which is where retval is allocated. It turns
out that if offsetGet() throws an exception, zend_std_read_dimension()
does not free the return zval, and it leaks. This only affects PHP 5.2.
The patch to fix is at http://pear.php.net/~greg/fix_leak.patch.txt and
is pasted below
Reproduce code:
---
Index: Zend/zend_object_handlers.c
===
RCS file: /repository/ZendEngine2/zend_object_handlers.c,v
retrieving revision 1.135.2.6.2.28
diff -u -r1.135.2.6.2.28 zend_object_handlers.c
--- Zend/zend_object_handlers.c 21 Feb 2008 13:55:22 -
1.135.2.6.2.28
+++ Zend/zend_object_handlers.c 21 Jun 2008 17:33:18 -
@@ -469,6 +469,10 @@
return 0;
}
+ if (EG(exception)) {
+ zval_ptr_dtor(retval);
+ return 0;
+ }
/* Undo PZVAL_LOCK() */
retval-refcount--;
--
Edit this bug report at http://bugs.php.net/?id=45327edit=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
`!` as value for parameters, all chars after `!` will be skipped.
Example:
file `config.ini`
[test]
one = work fine
two = !work fine too
three = !does not work
Reproduce code:
---
?php
$cfg = parse_ini_file('config.in');
print_r($cfg);
?
Expected result:
Array ( [one] = work fine [two] = !work fine too [three] =
--
Edit this bug report at http://bugs.php.net/?id=45974edit=1
#45976 [NEW]: SPL fails to load if simplexml is not loaded
From: development at domain51 dot com Operating system: OS X PHP version: 5.3CVS-2008-09-02 (CVS) PHP Bug Type: SPL related Bug description: SPL fails to load if simplexml is not loaded Description: When the SimpleXML extension is not loaded, SPL fails to load. Reproduce code: --- $ ./configure --disable-simplexml make make install $ php -v Expected result: PHP 5.3.0alpha3-dev (cli) (built: Sep 2 2008 11:09:22) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies Actual result: -- PHP Warning: Cannot load module 'SPL' because required module 'simplexml' is not loaded in Unknown on line 0 PHP 5.3.0alpha3-dev (cli) (built: Sep 2 2008 11:09:22) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies -- Edit bug report at http://bugs.php.net/?id=45976edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45976r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45976r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45976r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45976r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45976r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45976r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45976r=needscript Try newer version:http://bugs.php.net/fix.php?id=45976r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45976r=support Expected behavior:http://bugs.php.net/fix.php?id=45976r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45976r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45976r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45976r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45976r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45976r=dst IIS Stability:http://bugs.php.net/fix.php?id=45976r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45976r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45976r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45976r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45976r=mysqlcfg
#45954 [Bgs]: memory leak with unset(array)
ID: 45954
User updated by: mail at milianw dot de
Reported By: mail at milianw dot de
Status: Bogus
Bug Type: Performance problem
Operating System: *
PHP Version: 5.2.6
New Comment:
Yes, thank you. Thats an explanation which clarifies things for me.
Though one last thing: I was not speaking about a memory leak which
persists after the process is finished, but one while the process is
running. I was interested because while optimizing GeSHi I searched
for ways to reduce the memory consumption / memory peaks and spotted
this behaviour.
You can close this bug. Thanks again.
Previous Comments:
[2008-09-02 08:44:04] [EMAIL PROTECTED]
The internal memory manager is keeping tabs of the memory and will
reuse
it again if there is a memory allocation that it can fit in the block.
You can use valgrind and see that the memory is in fact free'd when the
request ends.
[2008-09-01 17:48:18] mail at milianw dot de
So there is simply no way at all to delete / free / unset variables in
PHP? But why does it work perfectly (i.e. like I imagine it should) when
I unset a string, even a very large one? That one frees the memory
instantaneously. But not so for arrays.
I simply cannot see the reasoning behind this. When a programmer calls
unset he seems to know that this very variable can be freed, or not? So
why do we need to wait for a GC to step in and do the actual cleanup? As
far as my limited knowledge goes manual delete/free is compatible with a
GC, or not? Or is it only possible to free simple strings, ints etc. but
not arrays?
Take this code:
?php
function foo() {
$string = '';
for ($i = 0; $i 1000; ++$i) {
$string .= 'asdfasdfasdf';
}
}
$i = 0;
echo setup:\t.memory_get_usage().\n;
for (; $i 10; ++$i) {
foo();
echo run $i:\t.memory_get_usage().\n;
}
Output:
setup: 65524
run 0: 66108
run 1: 66184
run 2: 66248
and constant thereafter.
If I know change the code slightly:
?php
function foo() {
$array = '';
for ($i = 0; $i 1000; ++$i) {
$array[] = 'asdfasdfasdf';
}
}
$i = 0;
echo setup:\t.memory_get_usage().\n;
for (; $i 10; ++$i) {
foo();
echo run $i:\t.memory_get_usage().\n;
}
The output becomes:
setup: 65364
run 0: 130356
run 1: 130364
run 2: 130384
run 3: 130344
and thereafter either that value or 130364
Ok - it's not a leak per se, yet I wonder: A function I called which
setup an array should free that memory (or should get its memory freed)
after stepping out of it's scope, no? Just like it does with strings...
Also: I can append the following code to the last snippet to verify
that the memory is _never_ freed:
while (true) {
echo memory_get_usage().\n;
}
I actually altered it a bit to break when the memory consumption
changes, and could potentially wait for hours.
So is this really no bug? Could it not be that e.g. some internal hash
pointers are left behind without getting deleted?
[2008-08-31 00:28:28] [EMAIL PROTECTED]
unset() is not free(). PHP uses memory manager that does the actual
garbage cleanup during request shutdown.
[2008-08-30 16:12:43] mail at milianw dot de
Description:
When you setup an array and unset() it afterwards, not all memory is
freed. I've run the code below on various PHP versions, including 5.2.6
(via Xampp) on Linux and Windows and always get output like:
startup:64296
array setup:13789672
unsetted array: 129284
The end value is more than twice as large as the start value.
Also interestingly is that low values in the for loop [e.g. for($i = 0;
$i 1; ++$i)] result in outputs like
startup: 64296
array setup:64864
unsetted array: 64864
Could it be that unset() relies on the Garbage Collector to do the work
instead of really destroying the variables? But then I find it strange
that even if I put a sleep(10) after the unset I still get the same
outputs for unsetted array.
Reproduce code:
---
?php
echo startup:.memory_get_usage().\n;
$array = array();
for ($i = 0; $i 10; ++$i) {
$array[] = 'foobar';
}
echo array setup:.memory_get_usage().\n;
unset($array);
echo unsetted array: .memory_get_usage().\n;
Expected result:
My expectations would be that the value reported at the end would be
nearly equal to the startup value.
Additionally a call to unset() should (imo) not rely on the GC but do
the deleting itself instantaneously.
NOTE: I've seen
#45977 [NEW]: strtotime returns time() with any string that begins with 'eat'
From: phocis at gmail dot com
Operating system: BSD
PHP version: 5.2.6
PHP Bug Type: Date/time related
Bug description: strtotime returns time() with any string that begins with
'eat'
Description:
Strtotime returns time() with any string that begins with 'eat'
While this is related to: http://bugs.php.net/bug.php?id=43960
It is not exactly the same.
Reproduce code:
---
var_dump(strtotime('10 September 2000'));
var_dump(strtotime('10 September 2000 asdfasdfasdf'));
var_dump(strtotime('asdfasdfasdf 10 September 2000'));
var_dump(strtotime('eat'));
var_dump(strtotime('eat asdfasdfasdf'));
var_dump(strtotime('asdfasdfasdf eat'));
var_dump(strtotime('EAT'));
Expected result:
int(968569200) # 10 sept 200
bool(false)
bool(false)
bool(false)
bool(false)
bool(false)
bool(false)
Actual result:
--
int(968569200) # 10 sept 200
bool(false)
bool(false)
int(1220360063) # time()
int(1220360063) # time()
bool(false)
int(1220360063) # time()
--
Edit bug report at http://bugs.php.net/?id=45977edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45977r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45977r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45977r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45977r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45977r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45977r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45977r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45977r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45977r=support
Expected behavior:http://bugs.php.net/fix.php?id=45977r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45977r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45977r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45977r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45977r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45977r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45977r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45977r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45977r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45977r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45977r=mysqlcfg
#45976 [Opn]: SPL fails to load if simplexml is not loaded
ID: 45976 Updated by: [EMAIL PROTECTED] Reported By: development at domain51 dot com Status: Open Bug Type: SPL related Operating System: OS X PHP Version: 5.3CVS-2008-09-02 (CVS) New Comment: What exactly is bugged about this according to you? SPL requires simpleXML, which you explicitly disallow. Seems pretty straightforward to me? enable simpleXML and SPL will load just fine again. Previous Comments: [2008-09-02 16:52:18] development at domain51 dot com Description: When the SimpleXML extension is not loaded, SPL fails to load. Reproduce code: --- $ ./configure --disable-simplexml make make install $ php -v Expected result: PHP 5.3.0alpha3-dev (cli) (built: Sep 2 2008 11:09:22) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies Actual result: -- PHP Warning: Cannot load module 'SPL' because required module 'simplexml' is not loaded in Unknown on line 0 PHP 5.3.0alpha3-dev (cli) (built: Sep 2 2008 11:09:22) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies -- Edit this bug report at http://bugs.php.net/?id=45976edit=1
#45977 [Opn-Bgs]: strtotime returns time() with any string that begins with 'eat'
ID: 45977
User updated by: phocis at gmail dot com
Reported By: phocis at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: BSD
PHP Version: 5.2.6
New Comment:
So, I read the other bug report's comments a little more thoroughly and
found out about Double timezone specifications.
What I really wanted was a is_perfect_time:
function is_perfect_time($time){
$parsed = date_parse($time);
return (
$parsed['error_count'] === 0
$parsed['warning_count'] === 0
);
}
Sorry for the premature bug report.
-Carl
Previous Comments:
[2008-09-02 22:57:05] phocis at gmail dot com
Description:
Strtotime returns time() with any string that begins with 'eat'
While this is related to: http://bugs.php.net/bug.php?id=43960
It is not exactly the same.
Reproduce code:
---
var_dump(strtotime('10 September 2000'));
var_dump(strtotime('10 September 2000 asdfasdfasdf'));
var_dump(strtotime('asdfasdfasdf 10 September 2000'));
var_dump(strtotime('eat'));
var_dump(strtotime('eat asdfasdfasdf'));
var_dump(strtotime('asdfasdfasdf eat'));
var_dump(strtotime('EAT'));
Expected result:
int(968569200) # 10 sept 200
bool(false)
bool(false)
bool(false)
bool(false)
bool(false)
bool(false)
Actual result:
--
int(968569200) # 10 sept 200
bool(false)
bool(false)
int(1220360063) # time()
int(1220360063) # time()
bool(false)
int(1220360063) # time()
--
Edit this bug report at http://bugs.php.net/?id=45977edit=1
#45976 [Opn]: SPL fails to load if simplexml is not loaded
ID: 45976 User updated by: development at domain51 dot com Reported By: development at domain51 dot com Status: Open Bug Type: SPL related Operating System: OS X PHP Version: 5.3CVS-2008-09-02 (CVS) New Comment: The problem is that SimpleXML should not be something that can be disabled if it is required for SPL and SPL can not be disabled. This will break all manner of debian packages that compile with --disable-all used. Previous Comments: [2008-09-02 23:20:34] [EMAIL PROTECTED] What exactly is bugged about this according to you? SPL requires simpleXML, which you explicitly disallow. Seems pretty straightforward to me? enable simpleXML and SPL will load just fine again. [2008-09-02 16:52:18] development at domain51 dot com Description: When the SimpleXML extension is not loaded, SPL fails to load. Reproduce code: --- $ ./configure --disable-simplexml make make install $ php -v Expected result: PHP 5.3.0alpha3-dev (cli) (built: Sep 2 2008 11:09:22) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies Actual result: -- PHP Warning: Cannot load module 'SPL' because required module 'simplexml' is not loaded in Unknown on line 0 PHP 5.3.0alpha3-dev (cli) (built: Sep 2 2008 11:09:22) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies -- Edit this bug report at http://bugs.php.net/?id=45976edit=1
#45976 [Opn-Asn]: SPL fails to load if simplexml is not loaded
ID: 45976 Updated by: [EMAIL PROTECTED] Reported By: development at domain51 dot com -Status: Open +Status: Assigned Bug Type: SPL related Operating System: OS X PHP Version: 5.3CVS-2008-09-02 (CVS) -Assigned To: +Assigned To: helly New Comment: No, the behavior is wrong, the configure system should fail not create an invalid build. The question is: Should we enforce the availability of SimpleXML or not? Without too much thinking I tend to say no, and thinking a bit more I'm wondering if it makes sense to move SimpleXMLIterator from SPL to SimpleXML then we could get rid of that dependency. Marcus, what's your opinion on this? Previous Comments: [2008-09-02 23:40:33] development at domain51 dot com The problem is that SimpleXML should not be something that can be disabled if it is required for SPL and SPL can not be disabled. This will break all manner of debian packages that compile with --disable-all used. [2008-09-02 23:20:34] [EMAIL PROTECTED] What exactly is bugged about this according to you? SPL requires simpleXML, which you explicitly disallow. Seems pretty straightforward to me? enable simpleXML and SPL will load just fine again. [2008-09-02 16:52:18] development at domain51 dot com Description: When the SimpleXML extension is not loaded, SPL fails to load. Reproduce code: --- $ ./configure --disable-simplexml make make install $ php -v Expected result: PHP 5.3.0alpha3-dev (cli) (built: Sep 2 2008 11:09:22) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies Actual result: -- PHP Warning: Cannot load module 'SPL' because required module 'simplexml' is not loaded in Unknown on line 0 PHP 5.3.0alpha3-dev (cli) (built: Sep 2 2008 11:09:22) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies -- Edit this bug report at http://bugs.php.net/?id=45976edit=1
#45977 [Bgs]: strtotime returns time() with any string that begins with 'eat'
ID: 45977
Updated by: [EMAIL PROTECTED]
Reported By: phocis at gmail dot com
Status: Bogus
Bug Type: Date/time related
Operating System: BSD
PHP Version: 5.2.6
New Comment:
EAT is East Africa Time, hence its valid.
Previous Comments:
[2008-09-02 23:34:21] phocis at gmail dot com
So, I read the other bug report's comments a little more thoroughly and
found out about Double timezone specifications.
What I really wanted was a is_perfect_time:
function is_perfect_time($time){
$parsed = date_parse($time);
return (
$parsed['error_count'] === 0
$parsed['warning_count'] === 0
);
}
Sorry for the premature bug report.
-Carl
[2008-09-02 22:57:05] phocis at gmail dot com
Description:
Strtotime returns time() with any string that begins with 'eat'
While this is related to: http://bugs.php.net/bug.php?id=43960
It is not exactly the same.
Reproduce code:
---
var_dump(strtotime('10 September 2000'));
var_dump(strtotime('10 September 2000 asdfasdfasdf'));
var_dump(strtotime('asdfasdfasdf 10 September 2000'));
var_dump(strtotime('eat'));
var_dump(strtotime('eat asdfasdfasdf'));
var_dump(strtotime('asdfasdfasdf eat'));
var_dump(strtotime('EAT'));
Expected result:
int(968569200) # 10 sept 200
bool(false)
bool(false)
bool(false)
bool(false)
bool(false)
bool(false)
Actual result:
--
int(968569200) # 10 sept 200
bool(false)
bool(false)
int(1220360063) # time()
int(1220360063) # time()
bool(false)
int(1220360063) # time()
--
Edit this bug report at http://bugs.php.net/?id=45977edit=1
#45978 [NEW]: round() errors.
From: firealwaysworks at gmail dot com Operating system: Linux PHP version: 5.2.6 PHP Bug Type: Math related Bug description: round() errors. 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.br; print round(21.33*1.015,2).br; print round(21.33*1.015,4).br; 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 bug report at http://bugs.php.net/?id=45978edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45978r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45978r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45978r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45978r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45978r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45978r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45978r=needscript Try newer version:http://bugs.php.net/fix.php?id=45978r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45978r=support Expected behavior:http://bugs.php.net/fix.php?id=45978r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45978r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45978r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45978r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45978r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45978r=dst IIS Stability:http://bugs.php.net/fix.php?id=45978r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45978r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45978r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45978r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45978r=mysqlcfg
#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.br; print round(21.33*1.015,2).br; print round(21.33*1.015,4).br; 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=45978edit=1
#45978 [Bgs]: round() errors.
ID: 45978 User updated by: firealwaysworks at gmail dot com Reported By: firealwaysworks at gmail dot com Status: Bogus Bug Type: Math related Operating System: Linux PHP Version: 5.2.6 New Comment: Cool, but this is still an inconsistency. Any string value of the number is treated is differently then when passed to round(). This is still a very serious problem for us because we are storing all of this information in a SQL database, the number will be lost when we build the query. I think you'll tell me that you don't care if people loose money when they use your platform and that you'll tell me to use someone Else's code, like BC Math. I think that relying on 3rd party extensions to fix your mistakes is unprofessional. Peace Previous Comments: [2008-09-03 05:16:45] [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. 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. [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.br; print round(21.33*1.015,2).br; print round(21.33*1.015,4).br; 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=45978edit=1
