Bug #65384 [Com]: pg_last_notice test failures
Edit report at https://bugs.php.net/bug.php?id=65384&edit=1 ID: 65384 Comment by: ni...@php.net Reported by: ni...@php.net Summary:pg_last_notice test failures Status: Closed Type: Bug Package:PostgreSQL related PHP Version:5.5.2RC1 Assigned To:yohgaki Block user comment: N Private report: N New Comment: For anyone interested, the relevant commits are: * https://github.com/php/php-src/commit/e960eebfea1fccbb4a2f030949249d4d1d198728 * https://github.com/php/php-src/commit/7d538cf8dd41a2584c56ec4abfafd738f0fa1e31 > I've only committed the fix. Should I commit the fix to 5.4/5.5? I don't know about 5.4, but this should definitely go into 5.5 as we're also testing that on Travis ;) The 09notice.phpt test is still failing: TEST 5533/12097 [ext/pgsql/tests/09notice.phpt] DIFF 001+ Cannot find notice message in hash 002+ bool(false) 003+ 001- Notice: pg_query(): %s already a transaction in progress in %s on line %d 002- %s already a transaction in progress DONE That's also the last failing test on Travis, so once that's fixed we'll *finally* have a working build there :) Thanks for working on this! Previous Comments: [2013-08-20 05:28:40] yohg...@php.net > Setting error logging message solved issue. Setting error logging level solved issue. [2013-08-20 05:27:59] yohg...@php.net It was error logging setting. Setting error logging message solved issue. I've only committed the fix. Should I commit the fix to 5.4/5.5? [2013-08-18 07:43:23] yohg...@php.net > Could it just be that they configured client_min_messages=WARNING? Users can set it as SQL command. SET client_min_messages TO WARNING; It may be the reason why this test fails. I'll try to change message level to NOTICE to see if it helps. I'm not sure how NOTIFY command is handled by PostgreSQL, so it might not be related, though. There is request that stores all notice during session. I'll work on this request later. If pgsql module keep all of them, it may consume all available memory. Therefore, configuration for max number of notices recorded will be added. It may help to find out what is going on. [2013-08-09 20:35:53] m...@php.net Could it just be that they configured client_min_messages=WARNING? [2013-08-05 01:18:45] yohg...@php.net I cannot reproduce on my Fedora19 and PHP 5.5 branch [yohgaki@dev PHP-5.5]$ rpm -q postgresql postgresql-9.2.4-1.fc19.x86_64 Anyone know what the PostgreSQL version on Travis CI? 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=65384 -- Edit this bug report at https://bugs.php.net/bug.php?id=65384&edit=1
Bug #65485 [Com]: Cast gives different values in one way or the other
Edit report at https://bugs.php.net/bug.php?id=65485&edit=1
ID: 65485
Comment by: ni...@php.net
Reported by:stephane at it-asia dot com
Summary:Cast gives different values in one way or the other
Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: Windows 8 & Mint Maya
PHP Version:5.4.18
Block user comment: N
Private report: N
New Comment:
I think you misunderstood how the casts work:
An (int) cast rounds DOWN to the nearest integer (in all sane languages).
A (string) cast just converts the float to a string representation. This
representation has the precision specified with the "precision" ini setting.
So what you are comparing here is a down-round ( floor($f) ) with a
round-with-precision ( round($f, $prec) ). Of course the result will be
different.
Previous Comments:
[2013-08-20 09:46:50] stephane at it-asia dot com
Yes I know about the imprecision and the link, this is what you say all the
time here.
But if you THINK about the matter, the casting algorythm is different, and this
is WRONG.
Other languages found solutions for that. I can't believe in 2013 PHP still
cannot provide a reliable solution to make simple operation like
"multiplications" and int casting.
The cast algorythm for float -> string -> int is GOOD. It is ALL THE TIME.
The cast algorythm for float -> int is WRONG. It is ALL THE TIME.
Please implement the same solution in both sides, hence choose the good one.
[2013-08-20 09:02:04] johan...@php.net
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://www.floating-point-gui.de/
Thank you for your interest in PHP.
Casting to string will be imprecise, then doing cast to int will be imprecise
again. Two imprecisions increase the difference.
[2013-08-20 08:50:20] stephane at it-asia dot com
Description:
I have different value when I cast a double to int and when I cast to string
before casting to int.
I understand 39.48 is difficult to store in base 2.
The problem is the cast algorythm is not the same if you cast a float to int or
if you cast a float to string, This involves huges mistakes in accountancy
software. Whatever the way you choose (float -> int or float -> string -> int )
, you should have the same result at the end.
Please define the right way to process data in that case.
I have the same problem with almost every machines, Windows or Debian based.
Thanks !
Test script:
---
$d = "39.48" * "100";
print("39.48 * 100 : ");
var_dump ($d);
$i = (int) $d;
print("int: ");
var_dump ($i);
$s = (string) $d;
print("string: ");
var_dump ($s);
$i = (int) $s;
print("int: ");
var_dump ($i);
Expected result:
same value if you cast double => int and if you cast double => string => int
Actual result:
--
39.48 * 100 : double(3948)
int: int(3947)
string: string(4) "3948"
int: int(3948)
--
Edit this bug report at https://bugs.php.net/bug.php?id=65485&edit=1
Bug #65485 [Com]: Cast gives different values in one way or the other
Edit report at https://bugs.php.net/bug.php?id=65485&edit=1 ID: 65485 Comment by: ni...@php.net Reported by:stephane at it-asia dot com Summary:Cast gives different values in one way or the other Status: Not a bug Type: Bug Package:*General Issues Operating System: Windows 8 & Mint Maya PHP Version:5.4.18 Block user comment: N Private report: N New Comment: @stephane: Float-to-integer casts are the same across all languages, at least as far as I am aware. They are always truncations (i.e. they just take the integer portion of the number and drop the rest. For positive numbers truncation and floor are the same). I am sorry if this does not match your expectations, but this is standard behavior that everyone uses and we will not deviate from it. How integer to float casts work is documented here: http://www.php.net/manual/en/language.types.integer.php#language.types.integer.casting > When converting from float to integer, the number will be rounded towards > zero. See also the warning on that page, which deals with exactly your situation. In your case, what you are probably looking for is just the round() function, which will do a round towards the closest integer, rather than a round towards zero (truncation). Previous Comments: [2013-08-20 10:14:59] stephane at it-asia dot com I don't find sane to see a 3948 float value going to 3947 after an int casting, I really, really don't find it sane. I don't find sane as well to see the same number ending with different value after several casts. The cast doesn't provide the same precision when it is one case, ot the other. One uses floor(), when the other uses (round). And to be honest, one is obviously right, when the other is obviously wrong. Please provide examples where the float -> string -> int value doesn't give satisfaction. Because for me, the float -> int cast NEVER gives satisfaction when there's a decimal number involved. The right way is the way giving the right solution, It is not the one giving the wrong answer for the only pleasure to match impossibility theory. In every case, please add to the documentation that the float -> int cast gives stupid results because ti tends to respect a theoric lack orp precision, when the float -> string cast tends to provide a more acceptable answer. -------- [2013-08-20 09:53:17] ni...@php.net I think you misunderstood how the casts work: An (int) cast rounds DOWN to the nearest integer (in all sane languages). A (string) cast just converts the float to a string representation. This representation has the precision specified with the "precision" ini setting. So what you are comparing here is a down-round ( floor($f) ) with a round-with-precision ( round($f, $prec) ). Of course the result will be different. [2013-08-20 09:46:50] stephane at it-asia dot com Yes I know about the imprecision and the link, this is what you say all the time here. But if you THINK about the matter, the casting algorythm is different, and this is WRONG. Other languages found solutions for that. I can't believe in 2013 PHP still cannot provide a reliable solution to make simple operation like "multiplications" and int casting. The cast algorythm for float -> string -> int is GOOD. It is ALL THE TIME. The cast algorythm for float -> int is WRONG. It is ALL THE TIME. Please implement the same solution in both sides, hence choose the good one. [2013-08-20 09:02:04] johan...@php.net 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://www.floating-point-gui.de/ Thank you for your interest in PHP. Casting to string will be imprecise, then doing cast to int will be imprecise again. Two imprecisions increase the difference. [2013-08-20 08:50:20] stephane at it-asia dot com Description: I have different value when I cast a double to int and when I cast to string before casting to int. I understand 39.48 is difficult to store in base 2. The problem is the cast algorythm is not the same if you cast a float to int or if you cast a float to string, This involves huges mistakes in accountancy software. Whatever the way you
Bug #46311 [Com]: Pointer aliasing issue results in miscompile on gcc4.4
Edit report at https://bugs.php.net/bug.php?id=46311&edit=1 ID: 46311 Comment by: ni...@php.net Reported by:anton at samba dot org Summary:Pointer aliasing issue results in miscompile on gcc4.4 Status: Closed Type: Bug Package:Compile Failure Operating System: RHEL5.2 / PowerPC64 PHP Version:5.2.9 Assigned To:dmitry Block user comment: N Private report: N New Comment: Fixed in 5.5 and master. Previous Comments: [2013-08-22 09:06:22] ni...@php.net Automatic comment on behalf of nikic Revision: http://git.php.net/?p=php-src.git;a=commit;h=fc16b923135bf1670f6791d3998aeb19edde1ca5 Log: Fix bug #46311: Pointer aliasing issue results in miscompile on gcc4.4 [2013-08-22 07:34:33] olemar...@php.net Does it matter exactly where the bug is? It breaks compilation on arm and sparc as far as I can tell, and the patch is really simple. The problem is not caused by aggressive optimisations at least. I would not bother upstream with it if it was. [2013-03-19 19:24:12] dmi...@php.net This is not a PHP problem. The C code is absolutely legal and wrong compilation caused by a bug in GCC or too aggressive optimization options that make wrong assumptions. [2013-03-19 18:51:42] olemar...@php.net The Gentoo patchset has been running with this for years now. Any reason why this has not been resolved yet? [2010-07-25 02:17:06] mabi at gentoo dot org There are Gentoo downstream bugs related to this issue: https://bugs.gentoo.org/show_bug.cgi?id=295682 https://bugs.gentoo.org/show_bug.cgi?id=329753 I'd love to see this fixed upstream, but will ship a custom patch to get this more testing shortly. 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=46311 -- Edit this bug report at https://bugs.php.net/bug.php?id=46311&edit=1
Bug #65384 [Com]: pg_last_notice test failures
Edit report at https://bugs.php.net/bug.php?id=65384&edit=1 ID: 65384 Comment by: ni...@php.net Reported by: ni...@php.net Summary:pg_last_notice test failures Status: Closed Type: Bug Package:PostgreSQL related PHP Version:5.5.2RC1 Assigned To:yohgaki Block user comment: N Private report: N New Comment: I fixed the 09notice test and applied the changes to PHP 5.5 The Travis build now passes on master (and presumably also 5.5). Previous Comments: [2013-08-20 08:49:06] ni...@php.net For anyone interested, the relevant commits are: * https://github.com/php/php-src/commit/e960eebfea1fccbb4a2f030949249d4d1d198728 * https://github.com/php/php-src/commit/7d538cf8dd41a2584c56ec4abfafd738f0fa1e31 > I've only committed the fix. Should I commit the fix to 5.4/5.5? I don't know about 5.4, but this should definitely go into 5.5 as we're also testing that on Travis ;) The 09notice.phpt test is still failing: TEST 5533/12097 [ext/pgsql/tests/09notice.phpt] DIFF 001+ Cannot find notice message in hash 002+ bool(false) 003+ 001- Notice: pg_query(): %s already a transaction in progress in %s on line %d 002- %s already a transaction in progress DONE That's also the last failing test on Travis, so once that's fixed we'll *finally* have a working build there :) Thanks for working on this! [2013-08-20 05:28:40] yohg...@php.net > Setting error logging message solved issue. Setting error logging level solved issue. [2013-08-20 05:27:59] yohg...@php.net It was error logging setting. Setting error logging message solved issue. I've only committed the fix. Should I commit the fix to 5.4/5.5? [2013-08-18 07:43:23] yohg...@php.net > Could it just be that they configured client_min_messages=WARNING? Users can set it as SQL command. SET client_min_messages TO WARNING; It may be the reason why this test fails. I'll try to change message level to NOTICE to see if it helps. I'm not sure how NOTIFY command is handled by PostgreSQL, so it might not be related, though. There is request that stores all notice during session. I'll work on this request later. If pgsql module keep all of them, it may consume all available memory. Therefore, configuration for max number of notices recorded will be added. It may help to find out what is going on. [2013-08-09 20:35:53] m...@php.net Could it just be that they configured client_min_messages=WARNING? 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=65384 -- Edit this bug report at https://bugs.php.net/bug.php?id=65384&edit=1
Bug #65562 [Com]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562&edit=1 ID: 65562 Comment by: ni...@php.net Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg Status: Open Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: @johannes: Does this really need a test? The change is rather obvious after all. Introducing debug-only functions for this seems like overkill. Previous Comments: [2013-08-26 23:15:59] johan...@php.net A cleaner patch might pass the quiet argument to zend_parse_arg_impl, this would safe the allocation in there. This also seems to be limited to C and f modifiers which, in PHP itself, aren't used in combination with ZEND_PARSE_PARAMS_QUIET. So for adding a test we might need a deug-build-only functionin zend_builtin_functions.c. This might need coordination with docs and their function detection scripts. And sorry if I'm a bit harsh, but 99% of the internal API bugs we get are user errors and this bug was sparse on information. [2013-08-26 23:14:26] s...@php.net Waiting feedback on the patch [2013-08-26 23:07:33] rrh at newrelic dot com I will test the patch, and in the future come up with patches for your review. [2013-08-26 23:02:38] yohg...@php.net I suspect you have pointer issue. Valgrind does not handle ***(pointer to pointer to pointer) well. Check your hash handling code carefully, it may help. [2013-08-26 23:02:10] johan...@php.net meant to write "your problem" :-) 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=65562 -- Edit this bug report at https://bugs.php.net/bug.php?id=65562&edit=1
Req #61759 [Com]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759&edit=1 ID: 61759 Comment by: ni...@php.net Reported by:ahar...@php.net Summary:class_alias() should accept classes with leading backslashes Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Irrelevant PHP Version:master-Git-2012-04-18 (Git) Block user comment: N Private report: N New Comment: I'm not convinced that allowing a leading \ is something we should strive towards. The \ is unnecessary and redundant (as string names are always fully qualified). I'd rather allow only the canonical form. Previous Comments: [2013-08-27 12:04:43] jpa...@php.net Yep, let's start finding all places where classes as strings can be used, and patch them all to use zend_lookup_class(). There shouldn't be tons of them AFAIR. [2013-08-27 10:19:53] contact at jubianchi dot fr I agree with Johannes about consistency. The severity is not really is not very high and this use case can easily be handled at a useland level. As long as this behavior is not "fixed" I think a warning on the doc shoudl be enough, even if I'd like to see it fixed (but as I said, it's not a big deal at the moment). BTW, thanks for you work Julien :) [2013-08-27 10:08:00] johan...@php.net Technically we could, but it adds some inconsistency if one place allows this but others not and that should be avoided. [2013-08-27 09:46:53] jpa...@php.net The following patch has been added/updated: Patch Name: fix-class_alias Revision: 1377596813 URL: https://bugs.php.net/patch-display.php?bug=61759&patch=fix-class_alias&revision=1377596813 [2013-08-27 09:45:12] jpa...@php.net Johannes: I agree, but we could start by patching this bug report right? I got a patch here : https://github.com/jpauli/php- src/compare/class_alias_registration_fix 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=61759 -- Edit this bug report at https://bugs.php.net/bug.php?id=61759&edit=1
Bug #65784 [Com]: Segfault with finally
Edit report at https://bugs.php.net/bug.php?id=65784&edit=1
ID: 65784
Comment by: ni...@php.net
Reported by:r dot wilczek at web-appz dot de
Summary:Segfault with finally
Status: Open
Type: Bug
Package:*General Issues
Operating System: Linux
PHP Version:5.5.4
Block user comment: N
Private report: N
New Comment:
Could you please post the code as it is actually used (just the part containing
the finally)? Your backtrace indicates that the segfault happens during an
argument send, but your code samples do not include any function calls with
arguments.
Previous Comments:
[2013-09-29 12:26:34] r dot wilczek at web-appz dot de
(The second core-dump is created without xdebug, to keep things simple)
[2013-09-29 12:25:34] r dot wilczek at web-appz dot de
#0 0x00a41895 in zval_delref_p (pz=0x0) at
/root/php-5.5.4/php-5.5.4/Zend/zend.h:409
#1 0x00a4330c in zend_pzval_unlock_func (z=0x0,
should_free=0x7fffa8aa9e90, unref=1) at
/root/php-5.5.4/php-5.5.4/Zend/zend_execute.c:72
#2 0x00a4341b in _get_zval_ptr_var (var=4294967232,
execute_data=0x7f1fceaa5098, should_free=0x7fffa8aa9e90) at
/root/php-5.5.4/php-5.5.4/Zend/zend_execute.c:186
#3 0x00a63e15 in ZEND_SEND_VAR_NO_REF_SPEC_VAR_HANDLER
(execute_data=0x7f1fceaa5098) at
/root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:13081
#4 0x00a480cf in execute_ex (execute_data=0x7f1fceaa5098) at
/root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:363
#5 0x00a48157 in zend_execute (op_array=0x2e129f0) at
/root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:388
#6 0x009f6785 in zend_call_function (fci=0x7fffa8aaa100,
fci_cache=0x7fffa8aaa0d0) at
/root/php-5.5.4/php-5.5.4/Zend/zend_execute_API.c:939
#7 0x0076285c in zim_reflection_method_invokeArgs (ht=2,
return_value=0x2e3b2d0, return_value_ptr=0x0, this_ptr=0x2e3b450,
return_value_used=1)
at /root/php-5.5.4/php-5.5.4/ext/reflection/php_reflection.c:3018
#8 0x00a489de in zend_do_fcall_common_helper_SPEC
(execute_data=0x7f1fceaa49e8) at
/root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:550
#9 0x00a491b0 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7f1fceaa49e8) at
/root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:685
#10 0x00a480cf in execute_ex (execute_data=0x7f1fceaa49e8) at
/root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:363
#11 0x00a48157 in zend_execute (op_array=0x7f1fcead9b60) at
/root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:388
#12 0x00a0a27f in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.5.4/php-5.5.4/Zend/zend.c:1318
#13 0x00976e9e in php_execute_script (primary_file=0x7fffa8aad7a0) at
/root/php-5.5.4/php-5.5.4/main/main.c:2489
#14 0x00ab7ac7 in do_cli (argc=5, argv=0x263beb0) at
/root/php-5.5.4/php-5.5.4/sapi/cli/php_cli.c:994
#15 0x00ab8bff in main (argc=5, argv=0x263beb0) at
/root/php-5.5.4/php-5.5.4/sapi/cli/php_cli.c:1378
[2013-09-29 12:18:45] r dot wilczek at web-appz dot de
Description:
The structures
try {
return foo();
} finally {
bar();
}
or
try {
return foo();
} catch (Exception $e) {
throw $e;
} finally {
bar();
}
under some circumstances segfault, whereas the equivalent structure
try {
$result = foo();
bar();
return $result;
} catch (Exception $e) {
bar();
throw $e;
}
works as expected.
Test script:
---
It's hard to reproduce the failure, because it occured within a "PHPUnit Mock
Monster", and I failed to reproduce it with a simple script.
All I can show is the core-dump below, which is produced by a
try {
return foo();
} finally {
bar();
}
Expected result:
No Segmentation fault
Actual result:
--
Segmentation fault
#0 0x00a41895 in zval_delref_p (pz=0x0) at
/root/php-5.5.4/php-5.5.4/Zend/zend.h:409
#1 0x00a4330c in zend_pzval_unlock_func (z=0x0,
should_free=0x7fff17175fe0, unref=1)
at /root/php-5.5.4/php-5.5.4/Zend/zend_execute.c:72
#2 0x00a4341b in _get_zval_ptr_var (var=4294967232,
execute_data=0x7fea01fe0098, should_free=0x7fff17175fe0)
at /root/php-5.5.4/php-5.5.4/Zend/zend_execute.c:186
#3 0x00a63e15 in ZEND_SEND_VAR_NO_REF_SPEC_VAR_HANDLER
(execute_data=0x7fea01fe0098)
at /root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:13081
#4 0x00a4a772 in ZEND_USER_OPCODE_SPEC_HANDLER
(execute_data=0x7fea01fe0098)
at /root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:1119
#5 0x00a480cf in execute_ex (execute_data=0x7fea01fe0098) at
/root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:363
#6 0x
Bug #54740 [Com]: Ternary operator will not work with return by reference
Edit report at https://bugs.php.net/bug.php?id=54740&edit=1
ID: 54740
Comment by: ni...@php.net
Reported by:dukeofgaming at gmail dot com
Summary:Ternary operator will not work with return by
reference
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
@marrch: PHP has no concept of a general & operator that takes the "reference"
of a variable(whatever that's supposed to be). PHP only has a =& operator
(which is really "=&" and not a combination of "=" and "&") which expects a
variable on the right hand side. PHP also has a & modifier for function
arguments and return values.
If you want to do yourself and others a favor, write $foo =& $bar rather than
$foo = &$bar to make sure that there are no misunderstandings regarding this ;)
Previous Comments:
[2013-10-02 11:12:00] marrch dot caat at gmail dot com
Mike, I understand that. The second note tells I caanot return a reference to
an expression result, such as &$object->method() or &(new StdClass()) - I can
understand that. But the code sample I provided doesn't try to do that. To make
things even simplier, the following code still fails to compile:
$link = $flag ? &$a : &$b;
It doesn't try to return a reference to an expression, just a reference to a
viriable; It doesn't try doing anything that the following code doesn't:
if ($flag)
$link = &$a;
else
$link = &$b;
And maybi I'm really stupid, but after 10 years in PHP development I still
don't understand why the first code cannot be compiled :(
[2013-10-02 05:27:05] m...@php.net
I meant the documentation "Note:" (warning) not the user-contributed note.
[2013-10-01 20:35:33] marrch dot caat at gmail dot com
I thoroughly read the article you mentioned, Mike, but still don't understand
why the following code fails to compile:
$link = isset($i) ? (& $arr[$i]) : null;
- while the following works fine:
$link = &$arr[$i];
In this case, &$arr[$i] is a legal reference assignment, so the first code
should behave equal to
if (isset($i)) {
$link = &$arr[$i];
} else {
$link = null;
}
- but this code works fine, and mentioned above isn't even compiled. What's
wrong with it?
[2013-10-01 14:42:02] m...@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
Check the second note here:
http://php.net/manual/en/language.references.return.php
[2012-08-27 14:17:44] marrch dot caat at gmail dot com
This is a general problem with reference inside ternary operator. For ex., the
following script fails with the same error:
$link = isset($i) ? (& $arr[$i]) : null;
- while the following works fine:
$link = & $arr[$i];
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=54740
--
Edit this bug report at https://bugs.php.net/bug.php?id=54740&edit=1
[PHP-BUG] Bug #65821 [NEW]: By-ref foreach on property access of string offset segfaults
From: nikic
Operating system:
PHP version: 5.5.4
Package: Scripting Engine problem
Bug Type: Bug
Bug description:By-ref foreach on property access of string offset segfaults
Description:
This segfaults:
$str = "foo";
foreach ($str[0]->bar as &$baz) {}
Because http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_vm_def.h#1391 uses
var.ptr_ptr without NULL check (FETCH_OBJ_W with ZEND_FETCH_ADD_LOCK).
--
Edit bug report at https://bugs.php.net/bug.php?id=65821&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65821&r=trysnapshot54
Try a snapshot (PHP 5.5):
https://bugs.php.net/fix.php?id=65821&r=trysnapshot55
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65821&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65821&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65821&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65821&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65821&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65821&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65821&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65821&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65821&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65821&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65821&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65821&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65821&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65821&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65821&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65821&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65821&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65821&r=mysqlcfg
Bug #64877 [Com]: is_numeric() doesn't treat strings in binary notation as documented
Edit report at https://bugs.php.net/bug.php?id=64877&edit=1
ID: 64877
Comment by: ni...@php.net
Reported by:cmbecker69 at gmx dot de
Summary:is_numeric() doesn't treat strings in binary
notation as documented
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: any
PHP Version:5.4.0 and later
Block user comment: N
Private report: N
New Comment:
Related discussion for is_numeric_string:
http://markmail.org/message/ax2drcb6dolr5agl. General consensus is that we
would rather remove hex support than add support for binary and octal.
Previous Comments:
[2013-10-31 16:43:09] cmbecker69 at gmx dot de
| This is bugged also for hex numbers:
The results are as expected according to the documentation. Note,
that a hexadecimal number is only reported as being numeric, if it
is in hexadecimal string notation (i.e. starting with 0x). The first
example is correctly reported as being numeric, because the "e" is
recognized as starting the exponential part of the number.
[2013-10-31 16:08:45] daniele dot didomizio at eurac dot edu
This is bugged also for hex numbers:
print "526e948280122 " .(is_numeric("526e948280122") ? "numeric" : "not
numeric"). PHP_EOL;
print "526a948280122 ". (is_numeric("526a948280122") ? "numeric" : "not
numeric"). PHP_EOL;
print "0x526a948280122 ". (is_numeric("0x526a948280122") ? "numeric" : "not
numeric"). PHP_EOL;
print "526f948280122 ". (is_numeric("526f948280122") ? "numeric" : "not
numeric"). PHP_EOL;
output is:
526e948280122 numeric
526a948280122 not numeric
0x526a948280122 numeric
526f948280122 not numeric
tested with versions 5.5.4-1 and 5.4.4 (Debian version 5.4.4-14+deb7u5)
[2013-08-18 04:01:08] yohg...@php.net
> is_numeric()/intval() (many others) were not taken into account new format.
is_numeric()/intval() (may be others) were not taken into account new format.
[2013-08-18 03:46:48] yohg...@php.net
This problem was introduced when binary format integer was supported.
is_numeric()/intval() (many others) were not taken into account new format.
[2013-08-18 03:43:45] yohg...@php.net
Related to
https://bugs.php.net/bug.php?id=65418
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=64877
--
Edit this bug report at https://bugs.php.net/bug.php?id=64877&edit=1
[PHP-BUG] Req #60486 [NEW]: Add parameter to token_get_all for normalized output
From: nikic Operating system: PHP version: 5.4.0RC3 Package: *General Issues Bug Type: Feature/Change Request Bug description:Add parameter to token_get_all for normalized output Description: A all_tokens_as_arrays parameter should be added to token_get_all which would result in it returning a normalized output, i.e. return arrays for all tokens, including single char tokens. -- Edit bug report at https://bugs.php.net/bug.php?id=60486&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60486&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60486&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60486&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60486&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60486&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60486&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60486&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60486&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60486&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60486&r=support Expected behavior: https://bugs.php.net/fix.php?id=60486&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60486&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60486&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60486&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60486&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60486&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60486&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60486&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60486&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60486&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60486&r=mysqlcfg
Req #60486 [PATCH]: Add parameter to token_get_all for normalized output
Edit report at https://bugs.php.net/bug.php?id=60486&edit=1 ID: 60486 Patch added by: ni...@php.net Reported by: ni...@php.net Summary:Add parameter to token_get_all for normalized output Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.4.0RC3 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: token_get_all.patch Revision: 1323450945 URL: https://bugs.php.net/patch-display.php?bug=60486&patch=token_get_all.patch&revision=1323450945 Previous Comments: [2011-12-09 17:13:10] ni...@php.net Description: A all_tokens_as_arrays parameter should be added to token_get_all which would result in it returning a normalized output, i.e. return arrays for all tokens, including single char tokens. -- Edit this bug report at https://bugs.php.net/bug.php?id=60486&edit=1
Bug #52719 [Com]: array_walk_recursive crashes if third param of the function is by reference
Edit report at https://bugs.php.net/bug.php?id=52719&edit=1
ID: 52719
Comment by: ni...@php.net
Reported by:apouch at woozworld dot com
Summary:array_walk_recursive crashes if third param of the
function is by reference
Status: Feedback
Type: Bug
Package:Arrays related
Operating System: Linux
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Another test case: http://codepad.viper-7.com/Mw3DhS. You can observe the
memory corruption in the values that are output. Also you can simply toggle the
crash be removing the 'alpha' elements: http://codepad.viper-7.com/luVZw5 will
crash.
By the way, I could not reproduce the crash on a debug build (I get only leaks
there, too).
Previous Comments:
[2010-12-13 13:19:19] php at oxanvanleeuwen dot nl
This is still a problem with PHP 5.3.4. Strange is that it segfaults after the
call to array_walk_recursive; running is printed.
See this test script, which segfaults:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I get no crash but a memleak which is handled gracefully with current SVN.
No crash[Mon Aug 30 19:33:37 2010] Script: '-'
/home/johannes/src/php/php-src/branches/PHP_5_3/Zend/zend_execute_API.c(888) :
Freeing 0x00DEB060 (32 bytes), script=-
=== Total 1 memory leaks detected ===
[2010-08-27 22:42:39] apouch at woozworld dot com
Description:
This is something that changed between PHP 5.3.2 and PHP 5.3.3.
array_walk_recursive accepts a 3rd parameter for 'userdata'.
If:
- this parameter is an object AND
- the user-created function used as second parameter to array_walk_recursive
defines the third parameter by reference AND
- The array given as first parameter to array_walk_recursive is a
multi-dimensional array,
PHP crashes.
Test script:
---
$array = array('foo', 'bar' => array('taz'));
$foo = new stdClass();
array_walk_recursive($array, create_function('&$v, $k, &$u', ''), $foo);
echo 'No crash';
//This one works: array_walk_recursive($array, create_function('&$v, $k, $u',
''), $foo);
Expected result:
No Crash
Actual result:
--
PHP crashes
--
Edit this bug report at https://bugs.php.net/bug.php?id=52719&edit=1
Bug #52719 [PATCH]: array_walk_recursive crashes if third param of the function is by reference
Edit report at https://bugs.php.net/bug.php?id=52719&edit=1
ID: 52719
Patch added by: ni...@php.net
Reported by:apouch at woozworld dot com
Summary:array_walk_recursive crashes if third param of the
function is by reference
Status: Feedback
Type: Bug
Package:Arrays related
Operating System: Linux
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: array_walk_recursive.patch
Revision: 1327669602
URL:
https://bugs.php.net/patch-display.php?bug=52719&patch=array_walk_recursive.patch&revision=1327669602
Previous Comments:
[2011-12-23 11:42:08] nikita dot ppv at googlemail dot com
This issue was caused by
http://svn.php.net/viewvc?view=revision&revision=300371 which was commited as a
fix for https://bugs.php.net/bug.php?id=51552.
Basically for a recursive array walk the zval will be zval_ptr_dtor'd
prematurely and multiple times (every time it leaves one recursive array_walk
call). This leads to the memory corruption and in some cases to a segfault.
I'm not exactly sure what purpose that change served, at least the respective
phpt test runs cleanly if I revert the changeset.
----
[2011-12-21 16:16:47] ni...@php.net
Another test case: http://codepad.viper-7.com/Mw3DhS. You can observe the
memory corruption in the values that are output. Also you can simply toggle the
crash be removing the 'alpha' elements: http://codepad.viper-7.com/luVZw5 will
crash.
By the way, I could not reproduce the crash on a debug build (I get only leaks
there, too).
[2010-12-13 13:19:19] php at oxanvanleeuwen dot nl
This is still a problem with PHP 5.3.4. Strange is that it segfaults after the
call to array_walk_recursive; running is printed.
See this test script, which segfaults:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I get no crash but a memleak which is handled gracefully with current SVN.
No crash[Mon Aug 30 19:33:37 2010] Script: '-'
/home/johannes/src/php/php-src/branches/PHP_5_3/Zend/zend_execute_API.c(888) :
Freeing 0x00DEB060 (32 bytes), script=-
=== Total 1 memory leaks detected ===
[2010-08-27 22:42:39] apouch at woozworld dot com
Description:
This is something that changed between PHP 5.3.2 and PHP 5.3.3.
array_walk_recursive accepts a 3rd parameter for 'userdata'.
If:
- this parameter is an object AND
- the user-created function used as second parameter to array_walk_recursive
defines the third parameter by reference AND
- The array given as first parameter to array_walk_recursive is a
multi-dimensional array,
PHP crashes.
Test script:
---
$array = array('foo', 'bar' => array('taz'));
$foo = new stdClass();
array_walk_recursive($array, create_function('&$v, $k, &$u', ''), $foo);
echo 'No crash';
//This one works: array_walk_recursive($array, create_function('&$v, $k, $u',
''), $foo);
Expected result:
No Crash
Actual result:
--
PHP crashes
--
Edit this bug report at https://bugs.php.net/bug.php?id=52719&edit=1
[PHP-BUG] Bug #61046 [NEW]: Segfault when memory limit is hit while copying hash table
From: nikic Operating system: PHP version: 5.4.0RC7 Package: Reproducible crash Bug Type: Bug Bug description:Segfault when memory limit is hit while copying hash table Description: The attached test script triggers a segfault. It happens during the shutdown after the memory limit is reached in the byRef($array) line. Test script: --- https://bugs.php.net/bug.php?id=61046&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61046&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61046&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61046&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61046&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61046&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61046&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61046&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61046&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61046&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61046&r=support Expected behavior: https://bugs.php.net/fix.php?id=61046&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61046&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61046&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61046&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61046&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61046&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61046&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61046&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61046&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61046&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61046&r=mysqlcfg
Bug #61046 [Com]: Segfault when memory limit is hit while copying hash table
Edit report at https://bugs.php.net/bug.php?id=61046&edit=1 ID: 61046 Comment by: ni...@php.net Reported by: ni...@php.net Summary:Segfault when memory limit is hit while copying hash table Status: Open Type: Bug Package:Reproducible crash PHP Version:5.4.0RC7 Block user comment: N Private report: N New Comment: GDB Stacktrace: #0 zend_mm_remove_from_free_list (heap=0x88da8d8, mm_block=0xb7fc5308) at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:805 #1 0x083ad608 in _zend_mm_free_int (heap=0x88da8d8, p=0xb7fc52f0) at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:2101 #2 0x083cd657 in destroy_op_array (op_array=0x8a5d4c8, tsrm_ls=0x88d9050) at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:380 #3 0x083cd777 in zend_function_dtor (function=0x8a5d4c8) at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:124 #4 0x083e49ae in zend_hash_apply_deleter (ht=0x88dae70, p=0x8a5d498) at /home/nikic/dev/php-src-git/Zend/zend_hash.c:650 #5 0x083e63b1 in zend_hash_reverse_apply (ht=0x88dae70, apply_func=0x83c7310 , tsrm_ls=0x88d9050) at /home/nikic/dev/php-src-git/Zend/zend_hash.c:804 #6 0x083c7ecb in shutdown_executor (tsrm_ls=0x88d9050) at /home/nikic/dev/php-src-git/Zend/zend_execute_API.c:304 #7 0x083d7c11 in zend_deactivate (tsrm_ls=0x88d9050) at /home/nikic/dev/php-src-git/Zend/zend.c:934 #8 0x0836be33 in php_request_shutdown (dummy=0x0) at /home/nikic/dev/php-src-git/main/main.c:1782 #9 0x0848d723 in do_cli (argc=4, argv=0xb3b4, tsrm_ls=0x88d9050) at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1169 #10 0x0806eaa3 in main (argc=4, argv=0xb3b4) at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1356 Previous Comments: [2012-02-10 17:28:02] ni...@php.net Description: The attached test script triggers a segfault. It happens during the shutdown after the memory limit is reached in the byRef($array) line. Test script: --- https://bugs.php.net/bug.php?id=61046&edit=1
[PHP-BUG] Bug #61058 [NEW]: array_fill leaks if start index is PHP_INT_MAX
From: nikic Operating system: PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:array_fill leaks if start index is PHP_INT_MAX Description: http://lxr.php.net/opengrok/xref/PHP_TRUNK/ext/standard/array.c#1570. -- Edit bug report at https://bugs.php.net/bug.php?id=61058&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61058&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61058&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61058&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61058&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61058&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61058&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61058&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61058&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61058&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61058&r=support Expected behavior: https://bugs.php.net/fix.php?id=61058&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61058&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61058&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61058&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61058&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61058&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61058&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61058&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61058&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61058&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61058&r=mysqlcfg
[PHP-BUG] Bug #61059 [NEW]: array_fill leaks if start index is PHP_INT_MAX
From: nikic Operating system: PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:array_fill leaks if start index is PHP_INT_MAX Description: http://lxr.php.net/opengrok/xref/PHP_TRUNK/ext/standard/array.c#1570. -- Edit bug report at https://bugs.php.net/bug.php?id=61059&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61059&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61059&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61059&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61059&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61059&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61059&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61059&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61059&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61059&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61059&r=support Expected behavior: https://bugs.php.net/fix.php?id=61059&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61059&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61059&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61059&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61059&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61059&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61059&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61059&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61059&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61059&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61059&r=mysqlcfg
Bug #61054 [Com]: preg_match () matching end of line in text file of windows style make a mistake
Edit report at https://bugs.php.net/bug.php?id=61054&edit=1 ID: 61054 Comment by: ni...@php.net Reported by:gzpan123 at gmail dot com Summary:preg_match () matching end of line in text file of windows style make a mistake Status: Open Type: Bug Package:*Regular Expressions Operating System: Windows,linux all PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I don't really understand the issue you have from your example, but in general LF is the compile-default linebreak for PCRE. If you want to use a different linebreak character you can either compile PCRE with the appropriate option or specify a control option like (*CRLF) before your regular expression. Previous Comments: [2012-02-11 09:47:27] gzpan123 at gmail dot com windows,linux all meet this bug [2012-02-11 09:42:45] gzpan123 at gmail dot com Description: function:preg_ match() when processing text file of windows style like blow example,it get wrong the $matches[2] behind follow a character , Create a text file(test.txt) in windows，Content: hello guo hi jason test Test script: --- Expected result: Array ( [0] => hello guo [1] => hello [2] => guo ) hello guo helloguo Array ( [0] => hi jason [1] => hi [2] => jason ) hi jason hijason Array ( ) test Actual result: -- hello guo Array ( [0] => hello guo [1] => hello [2] => guo ) hi jason Array ( [0] => hi jason [1] => hi [2] => jason ) testArray ( ) test -- Edit this bug report at https://bugs.php.net/bug.php?id=61054&edit=1
[PHP-BUG] Bug #61072 [NEW]: Memory leak when restoring an exception handler
From: nikic
Operating system:
PHP version: Irrelevant
Package: *General Issues
Bug Type: Bug
Bug description:Memory leak when restoring an exception handler
Description:
The script:
$callback = function() { };
set_exception_handler($callback);
restore_exception_handler();
Leaks:
[Mon Feb 13 17:34:31 2012] Script: 'workingFile18.php'
/home/nikic/dev/php-src/Zend/zend_builtin_functions.c(1610) : Freeing
0xB7893050 (20 bytes), script=workingFile18.php
=== Total 1 memory leaks detected ===
Fixing it is just a matter of adding:
INIT_PZVAL(EG(user_exception_handler));
After http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_builtin_functions.c#1619.
--
Edit bug report at https://bugs.php.net/bug.php?id=61072&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61072&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61072&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61072&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61072&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61072&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61072&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61072&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61072&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61072&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61072&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61072&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61072&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61072&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61072&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61072&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61072&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61072&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61072&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61072&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61072&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61072&r=mysqlcfg
[PHP-BUG] Bug #61087 [NEW]: Memory leak in parse_ini_file when specifying invalid scanner mode
From: nikic
Operating system:
PHP version: Irrelevant
Package: *General Issues
Bug Type: Bug
Bug description:Memory leak in parse_ini_file when specifying invalid scanner
mode
Description:
parse_ini_file('emptyFile', false, 26);
Leaks:
Warning: Invalid scanner mode in /home/nikic/dev/my-
fuzzer/reproduceCode5_memoryLeak.php on line 3
[Tue Feb 14 18:36:56 2012] Script: 'reproduceCode5_memoryLeak.php'
/home/nikic/dev/php-src/main/streams/plain_wrapper.c(910) : Freeing
0xB780BE94
(36 bytes), script=reproduceCode5_memoryLeak.php
[Tue Feb 14 18:36:56 2012] Script: 'reproduceCode5_memoryLeak.php'
/home/nikic/dev/php-src/Zend/zend_stream.c(280) : Freeing 0xB780C908 (32
bytes), script=reproduceCode5_memoryLeak.php
=== Total 2 memory leaks detected ===
The reason is that the file handle is not closed correctly.
I was able to fix it using this simple patch:
diff --git a/Zend/zend_ini_scanner.c b/Zend/zend_ini_scanner.c
index 85fc74d..3b4e217 100644
--- a/Zend/zend_ini_scanner.c
+++ b/Zend/zend_ini_scanner.c
@@ -230,9 +230,12 @@ int zend_ini_open_file_for_scanning(zend_file_handle
*fh, i
char *buf;
size_t size;
- if (zend_stream_fixup(fh, &buf, &size TSRMLS_CC) == FAILURE ||
- init_ini_scanner(scanner_mode, fh TSRMLS_CC) == FAILURE
- ) {
+ if (zend_stream_fixup(fh, &buf, &size TSRMLS_CC) == FAILURE) {
+ return FAILURE;
+ }
+
+ if (init_ini_scanner(scanner_mode, fh TSRMLS_CC) == FAILURE) {
+ zend_file_handle_dtor(fh TSRMLS_CC);
return FAILURE;
}
--
Edit bug report at https://bugs.php.net/bug.php?id=61087&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61087&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61087&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61087&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61087&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61087&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61087&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61087&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61087&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61087&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61087&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61087&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61087&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61087&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61087&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61087&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61087&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61087&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61087&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61087&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61087&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61087&r=mysqlcfg
Bug #61087 [PATCH]: Memory leak in parse_ini_file when specifying invalid scanner mode
Edit report at https://bugs.php.net/bug.php?id=61087&edit=1
ID: 61087
Patch added by: ni...@php.net
Reported by: ni...@php.net
Summary:Memory leak in parse_ini_file when specifying
invalid scanner mode
Status: Open
Type: Bug
Package:*General Issues
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: parse_ini_file_memleak.patch
Revision: 1329242430
URL:
https://bugs.php.net/patch-display.php?bug=61087&patch=parse_ini_file_memleak.patch&revision=1329242430
Previous Comments:
[2012-02-14 17:51:09] ni...@php.net
Description:
parse_ini_file('emptyFile', false, 26);
Leaks:
Warning: Invalid scanner mode in /home/nikic/dev/my-
fuzzer/reproduceCode5_memoryLeak.php on line 3
[Tue Feb 14 18:36:56 2012] Script: 'reproduceCode5_memoryLeak.php'
/home/nikic/dev/php-src/main/streams/plain_wrapper.c(910) : Freeing 0xB780BE94
(36 bytes), script=reproduceCode5_memoryLeak.php
[Tue Feb 14 18:36:56 2012] Script: 'reproduceCode5_memoryLeak.php'
/home/nikic/dev/php-src/Zend/zend_stream.c(280) : Freeing 0xB780C908 (32
bytes), script=reproduceCode5_memoryLeak.php
=== Total 2 memory leaks detected ===
The reason is that the file handle is not closed correctly.
I was able to fix it using this simple patch:
diff --git a/Zend/zend_ini_scanner.c b/Zend/zend_ini_scanner.c
index 85fc74d..3b4e217 100644
--- a/Zend/zend_ini_scanner.c
+++ b/Zend/zend_ini_scanner.c
@@ -230,9 +230,12 @@ int zend_ini_open_file_for_scanning(zend_file_handle *fh, i
char *buf;
size_t size;
- if (zend_stream_fixup(fh, &buf, &size TSRMLS_CC) == FAILURE ||
- init_ini_scanner(scanner_mode, fh TSRMLS_CC) == FAILURE
- ) {
+ if (zend_stream_fixup(fh, &buf, &size TSRMLS_CC) == FAILURE) {
+ return FAILURE;
+ }
+
+ if (init_ini_scanner(scanner_mode, fh TSRMLS_CC) == FAILURE) {
+ zend_file_handle_dtor(fh TSRMLS_CC);
return FAILURE;
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=61087&edit=1
[PHP-BUG] Bug #61088 [NEW]: Memory leak in readline_callback_handler_install
From: nikic
Operating system:
PHP version: Irrelevant
Package: *General Issues
Bug Type: Bug
Bug description:Memory leak in readline_callback_handler_install
Description:
$callback = function() {};
readline_callback_handler_install('***', $callback);
Leaks:
***[Tue Feb 14 19:01:11 2012] Script: 'reproduceCode3_memoryLeak.php'
/home/nikic/dev/php-src/ext/readline/readline.c(579) : Freeing 0xB78618F4
(20
bytes), script=reproduceCode3_memoryLeak.php
=== Total 1 memory leaks detected ===
Reason is incorrect copying of a zval in
http://lxr.php.net/opengrok/xref/PHP_TRUNK/ext/readline/readline.c#579.
I was able to fix it using this simple patch:
diff --git a/ext/readline/readline.c b/ext/readline/readline.c
index 22521e6..c9389fc 100644
--- a/ext/readline/readline.c
+++ b/ext/readline/readline.c
@@ -576,9 +576,8 @@ PHP_FUNCTION(readline_callback_handler_install)
FREE_ZVAL(_prepped_callback);
}
- MAKE_STD_ZVAL(_prepped_callback);
- *_prepped_callback = *callback;
- zval_copy_ctor(_prepped_callback);
+ ALLOC_ZVAL(_prepped_callback);
+ MAKE_COPY_ZVAL(&callback, _prepped_callback);
rl_callback_handler_install(prompt, php_rl_callback_handler);
--
Edit bug report at https://bugs.php.net/bug.php?id=61088&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61088&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61088&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61088&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61088&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61088&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61088&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61088&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61088&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61088&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61088&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61088&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61088&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61088&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61088&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61088&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61088&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61088&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61088&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61088&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61088&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61088&r=mysqlcfg
Bug #61088 [PATCH]: Memory leak in readline_callback_handler_install
Edit report at https://bugs.php.net/bug.php?id=61088&edit=1
ID: 61088
Patch added by: ni...@php.net
Reported by: ni...@php.net
Summary:Memory leak in readline_callback_handler_install
Status: Open
Type: Bug
Package:*General Issues
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: readline.patch
Revision: 1329243283
URL:
https://bugs.php.net/patch-display.php?bug=61088&patch=readline.patch&revision=1329243283
Previous Comments:
[2012-02-14 18:14:25] ni...@php.net
Description:
$callback = function() {};
readline_callback_handler_install('***', $callback);
Leaks:
***[Tue Feb 14 19:01:11 2012] Script: 'reproduceCode3_memoryLeak.php'
/home/nikic/dev/php-src/ext/readline/readline.c(579) : Freeing 0xB78618F4 (20
bytes), script=reproduceCode3_memoryLeak.php
=== Total 1 memory leaks detected ===
Reason is incorrect copying of a zval in
http://lxr.php.net/opengrok/xref/PHP_TRUNK/ext/readline/readline.c#579.
I was able to fix it using this simple patch:
diff --git a/ext/readline/readline.c b/ext/readline/readline.c
index 22521e6..c9389fc 100644
--- a/ext/readline/readline.c
+++ b/ext/readline/readline.c
@@ -576,9 +576,8 @@ PHP_FUNCTION(readline_callback_handler_install)
FREE_ZVAL(_prepped_callback);
}
- MAKE_STD_ZVAL(_prepped_callback);
- *_prepped_callback = *callback;
- zval_copy_ctor(_prepped_callback);
+ ALLOC_ZVAL(_prepped_callback);
+ MAKE_COPY_ZVAL(&callback, _prepped_callback);
rl_callback_handler_install(prompt, php_rl_callback_handler);
--
Edit this bug report at https://bugs.php.net/bug.php?id=61088&edit=1
Bug #61095 [Com]: PHP can't add hex numbers
Edit report at https://bugs.php.net/bug.php?id=61095&edit=1 ID: 61095 Comment by: ni...@php.net Reported by:tomek at przeslij dot pl Summary:PHP can't add hex numbers Status: Open Type: Bug Package:Math related Operating System: Windows XP PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Nice catch! This can be fixed by adding a len == 0 check after the while loop in http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_language_scanner.l#1515 (and returning 0 in that case). Previous Comments: [2012-02-15 15:54:47] anon at anon dot anon That is fan-tastic! http://i.imgur.com/uPC2b.gif [2012-02-15 15:32:20] tomek at przeslij dot pl Description: These echoes 4: echo (0x00+2); echo (0x00+0x02); but they should echo 2! This echoes 2 as expected: echo (0x00 + 2); Test script: --- echo (0x00+2); Expected result: 2 Actual result: -- 4 -- Edit this bug report at https://bugs.php.net/bug.php?id=61095&edit=1
[PHP-BUG] Bug #61097 [NEW]: Memory leak in xmlrpc functions copying zvals
From: nikic Operating system: PHP version: 5.4.0RC7 Package: XMLRPC-EPI related Bug Type: Bug Bug description:Memory leak in xmlrpc functions copying zvals Description: This will produce a leak in both functions: $method = 'abc'; xmlrpc_server_register_introspection_callback(xmlrpc_server_create(), $method); xmlrpc_server_register_method(xmlrpc_server_create(), 'abc', $method); -- Edit bug report at https://bugs.php.net/bug.php?id=61097&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61097&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61097&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61097&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61097&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61097&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61097&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61097&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61097&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61097&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61097&r=support Expected behavior: https://bugs.php.net/fix.php?id=61097&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61097&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61097&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61097&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61097&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61097&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61097&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61097&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61097&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61097&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61097&r=mysqlcfg
Bug #61097 [PATCH]: Memory leak in xmlrpc functions copying zvals
Edit report at https://bugs.php.net/bug.php?id=61097&edit=1 ID: 61097 Patch added by: ni...@php.net Reported by: ni...@php.net Summary:Memory leak in xmlrpc functions copying zvals Status: Open Type: Bug Package:XMLRPC-EPI related PHP Version:5.4.0RC7 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: xmlrpc.patch Revision: 1329330001 URL: https://bugs.php.net/patch-display.php?bug=61097&patch=xmlrpc.patch&revision=1329330001 Previous Comments: [2012-02-15 18:11:16] ni...@php.net Description: This will produce a leak in both functions: $method = 'abc'; xmlrpc_server_register_introspection_callback(xmlrpc_server_create(), $method); xmlrpc_server_register_method(xmlrpc_server_create(), 'abc', $method); -- Edit this bug report at https://bugs.php.net/bug.php?id=61097&edit=1
[PHP-BUG] Bug #61106 [NEW]: Segfault when using header_register_callback
From: nikic Operating system: PHP version: Irrelevant Package: Reproducible crash Bug Type: Bug Bug description:Segfault when using header_register_callback Description: Using header_register_callback may cause crashes due to a double zval_ptr_dtor. The double zval_ptr_dtor occurs in http://lxr.php.net/xref/PHP_TRUNK/main/SAPI.c#sapi_deactivate in lines http://lxr.php.net/xref/PHP_TRUNK/main/SAPI.c#498 and http://lxr.php.net/xref/PHP_TRUNK/main/SAPI.c#546. For me the issue is quite hard to reproduce reliably (especially after accidentally removing my only non-random reproduce script ^^), but I think it should be obvious that the double dtoring can cause a segfault if you try hard. The issue can be fixed by removing one of the two calls. -- Edit bug report at https://bugs.php.net/bug.php?id=61106&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61106&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61106&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61106&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61106&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61106&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61106&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61106&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61106&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61106&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61106&r=support Expected behavior: https://bugs.php.net/fix.php?id=61106&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61106&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61106&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61106&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61106&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61106&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61106&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61106&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61106&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61106&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61106&r=mysqlcfg
[PHP-BUG] Bug #61115 [NEW]: Stream related segfault on fatal error in php_stream_context_del_link
From: nikic Operating system: PHP version: 5.4.0RC7 Package: Reproducible crash Bug Type: Bug Bug description:Stream related segfault on fatal error in php_stream_context_del_link Description: links)); (gdb) bt #0 0x084c95cb in php_stream_context_del_link (context=0xb73cbddc, stream=0xb73cba00) at /home/nikic/dev/php-src/main/streams/streams.c:2256 #1 0x084c4953 in _php_stream_free (stream=0xb73cba00, close_options=3, tsrm_ls=0x8b26050) at /home/nikic/dev/php-src/main/streams/streams.c:449 #2 0x084c48a4 in _php_stream_free (stream=0xb73cbb90, close_options=11, tsrm_ls=0x8b26050) at /home/nikic/dev/php-src/main/streams/streams.c:406 #3 0x084c7059 in stream_resource_regular_dtor (rsrc=0xb73cbca0, tsrm_ls=0x8b26050) at /home/nikic/dev/php-src/main/streams/streams.c:1578 #4 0x085587f3 in list_entry_destructor (ptr=0xb73cbca0) at /home/nikic/dev/php-src/Zend/zend_list.c:183 #5 0x08555fc6 in zend_hash_apply_deleter (ht=0x8b280ac, p=0xb73cbc4c) at /home/nikic/dev/php-src/Zend/zend_hash.c:650 #6 0x08556154 in zend_hash_graceful_reverse_destroy (ht=0x8b280ac) at /home/nikic/dev/php-src/Zend/zend_hash.c:687 #7 0x085589d5 in zend_destroy_rsrc_list (ht=0x8b280ac, tsrm_ls=0x8b26050) at /home/nikic/dev/php-src/Zend/zend_list.c:239 #8 0x0854474a in zend_deactivate (tsrm_ls=0x8b26050) at /home/nikic/dev/php-src/Zend/zend.c:940 #9 0x084a6b4d in php_request_shutdown (dummy=0x0) at /home/nikic/dev/php-src/main/main.c:1781 #10 0x086907c5 in do_cli (argc=2, argv=0xb3d4, tsrm_ls=0x8b26050) at /home/nikic/dev/php-src/sapi/cli/php_cli.c:1169 #11 0x08691058 in main (argc=2, argv=0xb3d4) at /home/nikic/dev/php-src/sapi/cli/php_cli.c:1356 I was not yet able to understand the source of the segfault; would be nice if someone who knows the stream stuff better could give a hand :) -- Edit bug report at https://bugs.php.net/bug.php?id=61115&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61115&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61115&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61115&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61115&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61115&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61115&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61115&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61115&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61115&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61115&r=support Expected behavior: https://bugs.php.net/fix.php?id=61115&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61115&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61115&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61115&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61115&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61115&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61115&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61115&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61115&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61115&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61115&r=mysqlcfg
[PHP-BUG] Bug #61139 [NEW]: gzopen leaks when specifying invalid mode
From: nikic
Operating system:
PHP version: Irrelevant
Package: Zlib related
Bug Type: Bug
Bug description:gzopen leaks when specifying invalid mode
Description:
gzopen('someFile', 'c');
Leaks:
Warning: gzopen(): gzopen failed in
/home/nikic/dev/Phuzzy/results/reproduceCode9_gzopen_memoryLeak.php on line
3
/home/nikic/dev/php-src/trunk/main/streams/streams.c(509) : Stream of type
'STDIO' 0xb76e9024 (path:someFile) was not closed
[Sun Feb 19 15:20:17 2012] Script:
'reproduceCode9_gzopen_memoryLeak.php'
/home/nikic/dev/php-src/trunk/main/streams/streams.c(273) : Freeing
0xB76E9024
(140 bytes), script=reproduceCode9_gzopen_memoryLeak.php
/home/nikic/dev/php-src/trunk/ext/zlib/zlib_fopen_wrapper.c(131) : Actual
location (location was relayed)
=== Total 1 memory leaks detected ===
--
Edit bug report at https://bugs.php.net/bug.php?id=61139&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61139&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61139&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61139&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61139&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61139&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61139&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61139&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61139&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61139&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61139&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61139&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61139&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61139&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61139&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61139&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61139&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61139&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61139&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61139&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61139&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61139&r=mysqlcfg
Bug #61087 [PATCH]: Memory leak in parse_ini_file when specifying invalid scanner mode
Edit report at https://bugs.php.net/bug.php?id=61087&edit=1
ID: 61087
Patch added by: ni...@php.net
Reported by: ni...@php.net
Summary:Memory leak in parse_ini_file when specifying
invalid scanner mode
Status: Assigned
Type: Bug
Package:*General Issues
PHP Version:Irrelevant
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: parse_ini_file_memleak.patch
Revision: 1330018332
URL:
https://bugs.php.net/patch-display.php?bug=61087&patch=parse_ini_file_memleak.patch&revision=1330018332
Previous Comments:
[2012-02-14 18:00:30] ni...@php.net
The following patch has been added/updated:
Patch Name: parse_ini_file_memleak.patch
Revision: 1329242430
URL:
https://bugs.php.net/patch-display.php?bug=61087&patch=parse_ini_file_memleak.patch&revision=1329242430
[2012-02-14 17:51:09] ni...@php.net
Description:
parse_ini_file('emptyFile', false, 26);
Leaks:
Warning: Invalid scanner mode in /home/nikic/dev/my-
fuzzer/reproduceCode5_memoryLeak.php on line 3
[Tue Feb 14 18:36:56 2012] Script: 'reproduceCode5_memoryLeak.php'
/home/nikic/dev/php-src/main/streams/plain_wrapper.c(910) : Freeing 0xB780BE94
(36 bytes), script=reproduceCode5_memoryLeak.php
[Tue Feb 14 18:36:56 2012] Script: 'reproduceCode5_memoryLeak.php'
/home/nikic/dev/php-src/Zend/zend_stream.c(280) : Freeing 0xB780C908 (32
bytes), script=reproduceCode5_memoryLeak.php
=== Total 2 memory leaks detected ===
The reason is that the file handle is not closed correctly.
I was able to fix it using this simple patch:
diff --git a/Zend/zend_ini_scanner.c b/Zend/zend_ini_scanner.c
index 85fc74d..3b4e217 100644
--- a/Zend/zend_ini_scanner.c
+++ b/Zend/zend_ini_scanner.c
@@ -230,9 +230,12 @@ int zend_ini_open_file_for_scanning(zend_file_handle *fh, i
char *buf;
size_t size;
- if (zend_stream_fixup(fh, &buf, &size TSRMLS_CC) == FAILURE ||
- init_ini_scanner(scanner_mode, fh TSRMLS_CC) == FAILURE
- ) {
+ if (zend_stream_fixup(fh, &buf, &size TSRMLS_CC) == FAILURE) {
+ return FAILURE;
+ }
+
+ if (init_ini_scanner(scanner_mode, fh TSRMLS_CC) == FAILURE) {
+ zend_file_handle_dtor(fh TSRMLS_CC);
return FAILURE;
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=61087&edit=1
[PHP-BUG] Bug #61184 [NEW]: Phar::webPhar() generated headers with trailing NUL bytes
From: nikic Operating system: PHP version: Irrelevant Package: PHAR related Bug Type: Bug Bug description:Phar::webPhar() generated headers with trailing NUL bytes Description: Phar::webPhar() generates invalid 403, 404 and 301 headers, because the length of the headers in computed incorrectly, resulting in trailing NUL bytes to be sent. -- Edit bug report at https://bugs.php.net/bug.php?id=61184&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61184&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61184&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61184&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61184&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61184&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61184&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61184&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61184&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61184&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61184&r=support Expected behavior: https://bugs.php.net/fix.php?id=61184&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61184&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61184&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61184&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61184&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61184&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61184&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61184&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61184&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61184&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61184&r=mysqlcfg
Bug #61228 [Com]: htmlspecialchars() silently failing
Edit report at https://bugs.php.net/bug.php?id=61228&edit=1
ID: 61228
Comment by: ni...@php.net
Reported by:keisial at gmail dot com
Summary:htmlspecialchars() silently failing
Status: Open
Type: Bug
Package:Unknown/Other Function
PHP Version:5.4.0RC8
Block user comment: N
Private report: N
New Comment:
The main problem with that error was that it was very inconsistent:
It only was generated when error display was *disabled*. That basically meant
that you would never see that error in development, but it would flood your log
in production.
This was done for security reasons, in order to protect people who had
display_errors=1 on production servers.
Especially as PHP 5.4 provides ENT_SUBSTITUTE I think that this error doesn't
make much sense anymore.
But probably I'm wrong :)
Previous Comments:
[2012-03-01 20:39:49] keisial at gmail dot com
Description:
htmlspecialchars() no longer provides warnings in PHP 5.4
This is specially worrying as 5.4 changes its default charset
from ISO-8859-1 to UTF-8.
So the same string that passed flawlessly through 5.3, will
now silently output nothing in 5.4 (and htmlspecialchars
is one of the last things to check!).
In 5.3 the following can produce:
var_dump( htmlspecialchars("a\237a", ENT_COMPAT, 'UTF-8') );
PHP Warning: htmlspecialchars(): Invalid multibyte sequence in argument in php
shell code on line 1
string(0) ""
whereas in 5.4:
var_dump( htmlspecialchars("a\237a", ENT_COMPAT, 'UTF-8') );
string(0) ""
The explicit UTF-8 is to make both work the same,
htmlspecialchars("a\237a") *works* in 5.3 (but it may not be
in your page encoding).
The reason is clear, php_error_docref() of php_escape_html_entities_ex
is gone in 5.4 and trunk.
I attach a patch against 5.4 branch readding the warning (should apply fine in
trunk, moved 5 lines below)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61228&edit=1
Bug #60637 [Com]: Lexer is full of memory leaks
Edit report at https://bugs.php.net/bug.php?id=60637&edit=1
ID: 60637
Comment by: ni...@php.net
Reported by:nlop...@php.net
Summary:Lexer is full of memory leaks
Status: Open
Type: Bug
Package:Scripting Engine problem
PHP Version:trunk-SVN-2012-01-02 (SVN)
Block user comment: N
Private report: N
New Comment:
I can't reproduce this. How did you detect these leaks / in which form did they
manifest?
Previous Comments:
[2012-01-02 14:02:34] nlop...@php.net
Description:
zend_language_scanner.l has quite a big number of leaks:
- require('non-existent-file') - 2 leaks
- include('file-with-parse-error')
- every usage of zend_copy_value must be audited -- on a parse error it's
likely the memory will be leaked.
(run with USE_ZEND_ALLOC=0)
--
Edit this bug report at https://bugs.php.net/bug.php?id=60637&edit=1
Bug #60637 [Com]: Lexer is full of memory leaks
Edit report at https://bugs.php.net/bug.php?id=60637&edit=1
ID: 60637
Comment by: ni...@php.net
Reported by:nlop...@php.net
Summary:Lexer is full of memory leaks
Status: Open
Type: Bug
Package:Scripting Engine problem
PHP Version:trunk-SVN-2012-01-02 (SVN)
Block user comment: N
Private report: N
New Comment:
Ah, seems like I specified USE_ZEND_ALLOC=0 incorrectly.
Now getting this valgrind output for the require inexistent file case:
==8944==
==8944== HEAP SUMMARY:
==8944== in use at exit: 68,745 bytes in 2,588 blocks
==8944== total heap usage: 27,424 allocs, 24,836 frees, 1,842,625 bytes
allocated
==8944==
==8944== 136 bytes in 1 blocks are definitely lost in loss record 69 of 138
==8944==at 0x4028876: malloc (vg_replace_malloc.c:236)
==8944==by 0x850BF34: _emalloc (zend_alloc.c:2423)
==8944==by 0x84E40D2: compile_file (zend_language_scanner.l:548)
==8944==by 0x82E4393: phar_compile_file (phar.c:3391)
==8944==by 0x84E4419: compile_filename (zend_language_scanner.l:622)
==8944==by 0x858A90A: ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER
(zend_vm_execute.h:2592)
==8944==by 0x85806C8: execute (zend_vm_execute.h:410)
==8944==by 0x8545111: zend_execute_scripts (zend.c:1272)
==8944==by 0x84A8624: php_execute_script (main.c:2473)
==8944==by 0x868E8D0: do_cli (php_cli.c:983)
==8944==by 0x868FC4F: main (php_cli.c:1356)
==8944==
==8944== 211 bytes in 1 blocks are definitely lost in loss record 77 of 138
==8944==at 0x402896C: realloc (vg_replace_malloc.c:525)
==8944==by 0x850C08F: _erealloc (zend_alloc.c:2444)
==8944==by 0x84AC6F0: xbuf_format_converter (spprintf.c:777)
==8944==by 0x84AC9DC: vspprintf (spprintf.c:799)
==8944==by 0x84ACA3D: spprintf (spprintf.c:818)
==8944==by 0x84A3CEC: php_verror (main.c:832)
==8944==by 0x84A3FDC: php_error_docref0 (main.c:865)
==8944==by 0x84A5642: php_message_handler_for_zend (main.c:1372)
==8944==by 0x8543DE6: zend_message_dispatcher (zend.c:972)
==8944==by 0x84E41AD: compile_file (zend_language_scanner.l:568)
==8944==by 0x82E4393: phar_compile_file (phar.c:3391)
==8944==by 0x84E4419: compile_filename (zend_language_scanner.l:622)
==8944==
==8944== 252 (136 direct, 116 indirect) bytes in 1 blocks are definitely lost
in loss record 80 of 138
==8944==at 0x4028876: malloc (vg_replace_malloc.c:236)
==8944==by 0x850BF34: _emalloc (zend_alloc.c:2423)
==8944==by 0x84E40D2: compile_file (zend_language_scanner.l:548)
==8944==by 0x82E4393: phar_compile_file (phar.c:3391)
==8944==by 0x854500D: zend_execute_scripts (zend.c:1264)
==8944==by 0x84A8624: php_execute_script (main.c:2473)
==8944==by 0x868E8D0: do_cli (php_cli.c:983)
==8944==by 0x868FC4F: main (php_cli.c:1356)
==8944==
==8944== LEAK SUMMARY:
==8944==definitely lost: 483 bytes in 3 blocks
==8944==indirectly lost: 116 bytes in 4 blocks
==8944== possibly lost: 0 bytes in 0 blocks
==8944==still reachable: 68,146 bytes in 2,581 blocks
==8944== suppressed: 0 bytes in 0 blocks
==8944== Reachable blocks (those to which a pointer was found) are not shown.
==8944== To see them, rerun with: --leak-check=full --show-reachable=yes
==8944==
==8944== For counts of detected and suppressed errors, rerun with: -v
==8944== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 35 from 6)
I'm not sure how expected or not this is. All your cases are ones which will
cause a zend_bailout and unclean shutdown. I'm not sure those can really be
cleaned up correctly.
Previous Comments:
[2012-03-02 14:46:49] ni...@php.net
I can't reproduce this. How did you detect these leaks / in which form did they
manifest?
[2012-01-02 14:02:34] nlop...@php.net
Description:
zend_language_scanner.l has quite a big number of leaks:
- require('non-existent-file') - 2 leaks
- include('file-with-parse-error')
- every usage of zend_copy_value must be audited -- on a parse error it's
likely the memory will be leaked.
(run with USE_ZEND_ALLOC=0)
--
Edit this bug report at https://bugs.php.net/bug.php?id=60637&edit=1
[PHP-BUG] Bug #61264 [NEW]: xmlrpc_parse_method_descriptions leaks temporary variable
From: nikic Operating system: PHP version: Irrelevant Package: XMLRPC-EPI related Bug Type: Bug Bug description:xmlrpc_parse_method_descriptions leaks temporary variable Description: foo XML; var_dump(xmlrpc_parse_method_descriptions($xml)); Leaks, because the retval (http://lxr.php.net/xref/PHP_TRUNK/ext/xmlrpc/xmlrpc-epi-php.c#1240) is not dtor'd. -- Edit bug report at https://bugs.php.net/bug.php?id=61264&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61264&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61264&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61264&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61264&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61264&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61264&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61264&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61264&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61264&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61264&r=support Expected behavior: https://bugs.php.net/fix.php?id=61264&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61264&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61264&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61264&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61264&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61264&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61264&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61264&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61264&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61264&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61264&r=mysqlcfg
[PHP-BUG] Bug #61273 [NEW]: call_user_func_array with more than 16333 arguments leaks / crashes
From: nikic
Operating system:
PHP version: 5.4SVN-2012-03-04 (SVN)
Package: Reproducible crash
Bug Type: Bug
Bug description:call_user_func_array with more than 16333 arguments leaks /
crashes
Description:
The following code:
call_user_func_array(function(&$a) {}, $array = array_fill(0, 16334,
"*"));
Produces this output:
Warning: Parameter 1 to {closure}() expected to be a reference, value given
in Command line code on line 1
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_hash.c(832) : Freeing 0xB72FC03C
(36 bytes), script=-
/home/nikic/dev/php-src/trunk/Zend/zend_hash.c(412) : Actual location
(location was relayed)
Last leak repeated 16333 times
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_hash.c(376) : Freeing 0xB744103C
(65536 bytes), script=-
/home/nikic/dev/php-src/trunk/Zend/zend_alloc.c(2529) : Actual location
(location was relayed)
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_API.c(315) : Freeing 0xB74C0D50
(44 bytes), script=-
/home/nikic/dev/php-src/trunk/Zend/zend_variables.c(134) : Actual location
(location was relayed)
Last leak repeated 1 time
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_vm_execute.h(6788) : Freeing
0xB78560A8 (20 bytes), script=-
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_vm_execute.h(2378) : Freeing
0xB7857380 (2 bytes), script=-
/home/nikic/dev/php-src/trunk/Zend/zend_variables.c(121) : Actual location
(location was relayed)
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_vm_execute.h(2375) : Freeing
0xB7858360 (20 bytes), script=-
=== Total 16340 memory leaks detected ===
If you do some more stuff after the call PHP will eventually segfault.
This only happens if the *first* argument of the callback is by-ref and
only happens after a certain number of arguments (for me it starts with
16334). That's why I guess that this has something to do with
http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_execute_API.c#862 (i == 0 =>
branch not entered) and
http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_execute_API.c#851 (as it is
only for large argument numbers).
--
Edit bug report at https://bugs.php.net/bug.php?id=61273&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61273&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61273&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61273&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61273&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61273&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61273&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61273&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61273&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61273&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61273&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61273&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61273&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61273&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61273&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61273&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61273&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61273&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61273&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61273&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61273&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61273&r=mysqlcfg
Bug #61273 [Com]: call_user_func_array with more than 16333 arguments leaks / crashes
Edit report at https://bugs.php.net/bug.php?id=61273&edit=1
ID: 61273
Comment by: ni...@php.net
Reported by: ni...@php.net
Summary:call_user_func_array with more than 16333 arguments
leaks / crashes
Status: Open
Type: Bug
Package:Reproducible crash
PHP Version:5.4SVN-2012-03-04 (SVN)
Block user comment: N
Private report: N
New Comment:
Just checked with gdb and it seems that this indeed only happens if the stack
is resized.
Previous Comments:
[2012-03-04 15:24:11] ni...@php.net
Description:
The following code:
call_user_func_array(function(&$a) {}, $array = array_fill(0, 16334, "*"));
Produces this output:
Warning: Parameter 1 to {closure}() expected to be a reference, value given in
Command line code on line 1
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_hash.c(832) : Freeing 0xB72FC03C (36
bytes), script=-
/home/nikic/dev/php-src/trunk/Zend/zend_hash.c(412) : Actual location (location
was relayed)
Last leak repeated 16333 times
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_hash.c(376) : Freeing 0xB744103C
(65536 bytes), script=-
/home/nikic/dev/php-src/trunk/Zend/zend_alloc.c(2529) : Actual location
(location was relayed)
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_API.c(315) : Freeing 0xB74C0D50 (44
bytes), script=-
/home/nikic/dev/php-src/trunk/Zend/zend_variables.c(134) : Actual location
(location was relayed)
Last leak repeated 1 time
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_vm_execute.h(6788) : Freeing
0xB78560A8 (20 bytes), script=-
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_vm_execute.h(2378) : Freeing
0xB7857380 (2 bytes), script=-
/home/nikic/dev/php-src/trunk/Zend/zend_variables.c(121) : Actual location
(location was relayed)
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_vm_execute.h(2375) : Freeing
0xB7858360 (20 bytes), script=-
=== Total 16340 memory leaks detected ===
If you do some more stuff after the call PHP will eventually segfault.
This only happens if the *first* argument of the callback is by-ref and only
happens after a certain number of arguments (for me it starts with 16334).
That's why I guess that this has something to do with
http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_execute_API.c#862 (i == 0 => branch
not entered) and http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_execute_API.c#851
(as it is only for large argument numbers).
--
Edit this bug report at https://bugs.php.net/bug.php?id=61273&edit=1
Bug #61273 [Com]: call_user_func_array with more than 16333 arguments leaks / crashes
Edit report at https://bugs.php.net/bug.php?id=61273&edit=1
ID: 61273
Comment by: ni...@php.net
Reported by: ni...@php.net
Summary:call_user_func_array with more than 16333 arguments
leaks / crashes
Status: Open
Type: Bug
Package:Reproducible crash
PHP Version:5.4SVN-2012-03-04 (SVN)
Block user comment: N
Private report: N
New Comment:
The issue is indeed the if(i). Commenting it out fixes the problem.
Previous Comments:
[2012-03-04 15:33:18] ni...@php.net
Just checked with gdb and it seems that this indeed only happens if the stack
is resized.
[2012-03-04 15:24:11] ni...@php.net
Description:
The following code:
call_user_func_array(function(&$a) {}, $array = array_fill(0, 16334, "*"));
Produces this output:
Warning: Parameter 1 to {closure}() expected to be a reference, value given in
Command line code on line 1
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_hash.c(832) : Freeing 0xB72FC03C (36
bytes), script=-
/home/nikic/dev/php-src/trunk/Zend/zend_hash.c(412) : Actual location (location
was relayed)
Last leak repeated 16333 times
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_hash.c(376) : Freeing 0xB744103C
(65536 bytes), script=-
/home/nikic/dev/php-src/trunk/Zend/zend_alloc.c(2529) : Actual location
(location was relayed)
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_API.c(315) : Freeing 0xB74C0D50 (44
bytes), script=-
/home/nikic/dev/php-src/trunk/Zend/zend_variables.c(134) : Actual location
(location was relayed)
Last leak repeated 1 time
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_vm_execute.h(6788) : Freeing
0xB78560A8 (20 bytes), script=-
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_vm_execute.h(2378) : Freeing
0xB7857380 (2 bytes), script=-
/home/nikic/dev/php-src/trunk/Zend/zend_variables.c(121) : Actual location
(location was relayed)
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_vm_execute.h(2375) : Freeing
0xB7858360 (20 bytes), script=-
=== Total 16340 memory leaks detected ===
If you do some more stuff after the call PHP will eventually segfault.
This only happens if the *first* argument of the callback is by-ref and only
happens after a certain number of arguments (for me it starts with 16334).
That's why I guess that this has something to do with
http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_execute_API.c#862 (i == 0 => branch
not entered) and http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_execute_API.c#851
(as it is only for large argument numbers).
--
Edit this bug report at https://bugs.php.net/bug.php?id=61273&edit=1
Bug #61273 [PATCH]: call_user_func_array with more than 16333 arguments leaks / crashes
Edit report at https://bugs.php.net/bug.php?id=61273&edit=1
ID: 61273
Patch added by: ni...@php.net
Reported by: ni...@php.net
Summary:call_user_func_array with more than 16333 arguments
leaks / crashes
Status: Open
Type: Bug
Package:Reproducible crash
PHP Version:5.4SVN-2012-03-04 (SVN)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: call_user_func_array.patch
Revision: 1330876827
URL:
https://bugs.php.net/patch-display.php?bug=61273&patch=call_user_func_array.patch&revision=1330876827
Previous Comments:
[2012-03-04 15:53:11] ni...@php.net
The issue is indeed the if(i). Commenting it out fixes the problem.
[2012-03-04 15:33:18] ni...@php.net
Just checked with gdb and it seems that this indeed only happens if the stack
is resized.
[2012-03-04 15:24:11] ni...@php.net
Description:
The following code:
call_user_func_array(function(&$a) {}, $array = array_fill(0, 16334, "*"));
Produces this output:
Warning: Parameter 1 to {closure}() expected to be a reference, value given in
Command line code on line 1
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_hash.c(832) : Freeing 0xB72FC03C (36
bytes), script=-
/home/nikic/dev/php-src/trunk/Zend/zend_hash.c(412) : Actual location (location
was relayed)
Last leak repeated 16333 times
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_hash.c(376) : Freeing 0xB744103C
(65536 bytes), script=-
/home/nikic/dev/php-src/trunk/Zend/zend_alloc.c(2529) : Actual location
(location was relayed)
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_API.c(315) : Freeing 0xB74C0D50 (44
bytes), script=-
/home/nikic/dev/php-src/trunk/Zend/zend_variables.c(134) : Actual location
(location was relayed)
Last leak repeated 1 time
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_vm_execute.h(6788) : Freeing
0xB78560A8 (20 bytes), script=-
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_vm_execute.h(2378) : Freeing
0xB7857380 (2 bytes), script=-
/home/nikic/dev/php-src/trunk/Zend/zend_variables.c(121) : Actual location
(location was relayed)
[Sun Mar 4 16:17:15 2012] Script: '-'
/home/nikic/dev/php-src/trunk/Zend/zend_vm_execute.h(2375) : Freeing
0xB7858360 (20 bytes), script=-
=== Total 16340 memory leaks detected ===
If you do some more stuff after the call PHP will eventually segfault.
This only happens if the *first* argument of the callback is by-ref and only
happens after a certain number of arguments (for me it starts with 16334).
That's why I guess that this has something to do with
http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_execute_API.c#862 (i == 0 => branch
not entered) and http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_execute_API.c#851
(as it is only for large argument numbers).
--
Edit this bug report at https://bugs.php.net/bug.php?id=61273&edit=1
Bug #61356 [Com]: error_reporting always reports E_STRICT
Edit report at https://bugs.php.net/bug.php?id=61356&edit=1 ID: 61356 Comment by: ni...@php.net Reported by:dave dot kimble at gmx dot com Summary:error_reporting always reports E_STRICT Status: Open Type: Bug Package:PHP options/info functions Operating System: Windows 7 Ult 32 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Are you sure that you are modifying the correct .ini file? Also, did you restart your server after the changes? Previous Comments: [2012-03-12 09:28:44] dave dot kimble at gmx dot com Description: php-5.4.0-Win32-VC9-x86.zip downloaded 11 March 2012 php.ini as per php.ini-production with a few minor tweaks error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT sends E_STRICT messages to web page - potential security risk eg: Strict Standards: Non-static method ConvertUtils::AttributeQuote() should not be called statically in W:\domains\*.org.au\private_html\webmail\index.php on line 226 Nothing I do to error_reporting will switch it off. display_errors = Off doesn't seem to work either. Test script: --- AfterLogic Webmail http://www.afterlogic.com/download/webmail_php.zip unzip to /webmail and browse to /webmail/install needs MySQL, installs OK, then browse to /webmail/index.php to login login screens fills with E_STRICT messages and the form gets corrupted -- Edit this bug report at https://bugs.php.net/bug.php?id=61356&edit=1
Req #60738 [PATCH]: Allow 'set_error_handler' to handle NULL
Edit report at https://bugs.php.net/bug.php?id=60738&edit=1
ID: 60738
Patch added by: ni...@php.net
Reported by:four dot zerooneunauthorized at gmail dot com
Summary:Allow 'set_error_handler' to handle NULL
Status: Open
Type: Feature/Change Request
Package:Unknown/Other Function
Operating System: irrelivant
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: error_handler_patch_1.diff
Revision: 1332535845
URL:
https://bugs.php.net/patch-display.php?bug=60738&patch=error_handler_patch_1.diff&revision=1332535845
Previous Comments:
[2012-03-13 08:56:27] kevin dot swinton at gmail dot com
In the first instance, nothing in here relates to a bug, rather both are
feature requests.
The first request is for set_error_handler() to function in an identical way to
set_exception_handler() when called with a single NULL parameter. In the
interests of a more consistent API this would seem sensible.
The second request is for set_exception_handler() (and by extension
set_error_handler()) to behave in a different way when called with a single
NULL parameter.
Given there is no compelling argument, and that such a change could technically
break BC, and that the request in itself doesn't appear to achieve anything
useful, the suggestion would be that the first request could be implemented
whilst the second request has no case.
As a result, I have attached a patch to implement only the first request.
[2012-01-13 02:22:55] four dot zerooneunauthorized at gmail dot com
Description:
Can the 'set_error_handler' function be made to accept NULL as the parameter in
such a way as to reset this feature to the default state of -no- handler being
set? This would duplicate the behavior of the 'set_exception_handler' function.
Note: this change should not interfere with the 'restore_error_handler'
function.
And as for the 'set_exception_handler' function - if NULL is given as a
parameter, can the return value of 'set_exception_handler' be set to the
details of the previously set exception handler function (string or array)
instead of always '(bool) true' as it now does?
Test script:
---
function testhandler1($errno= null, $errstr= null, $errfile= null, $errline =
null)
{
error_log('1: ' . print_r(func_get_args(), true));
die();
}
function testhandler2($errno= null, $errstr= null, $errfile= null, $errline =
null)
{
error_log('2: ' . print_r(func_get_args(), true));
die();
}
var_dump(set_error_handler('testhandler1'));
var_dump(set_error_handler('testhandler2'));
var_dump(set_error_handler(null));
Expected result:
NULL
string(12) "testhandler1"
string(12) "testhandler2"
Actual result:
--
On line 'var_dump(set_error_handler(null));', a 'set_error_handler() expects
the argument () to be a valid callback' error is generated and handled by
function "testhandler2"
--
Edit this bug report at https://bugs.php.net/bug.php?id=60738&edit=1
Req #47136 [Com]: namespace reserved set_error|exception_handler
Edit report at https://bugs.php.net/bug.php?id=47136&edit=1
ID: 47136
Comment by: ni...@php.net
Reported by:info at netmosfera dot it
Summary:namespace reserved set_error|exception_handler
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: irrelevant
PHP Version:5.3.0alpha3
Block user comment: N
Private report: N
New Comment:
I don't understand this feature request. Do you mean that the error handler
should only catch errors thrown in that namespace? If so, then it doesn't make
sense as namespaces are only a mechanism of resolving names, they don't
interfere with the main code.
Previous Comments:
[2009-01-17 12:40:55] info at netmosfera dot it
Description:
hello
is possibile to define errors/exceptions handlers
reserved to namespaces?
because argument 2 is optional maybe it is hard to write
set_error_handler("debug", E_ALL, __NAMESPACE__);
so:
// for functions:
set_error_handler(array("", "debug", __NAMESPACE__));
// for classes (static way):
set_error_handler(array("myclass", "debug", __NAMESPACE__));
// for objects:
set_error_handler(array($this, "debug", __NAMESPACE__));
thank you
--
Edit this bug report at https://bugs.php.net/bug.php?id=47136&edit=1
Bug #61569 [Com]: Syntax error for calling a closure using array accesor on function call
Edit report at https://bugs.php.net/bug.php?id=61569&edit=1
ID: 61569
Comment by: ni...@php.net
Reported by:oxygenus at gmail dot com
Summary:Syntax error for calling a closure using array
accesor on function call
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: ANY
PHP Version:master
Block user comment: N
Private report: N
New Comment:
I mentioned this some time ago on internals, but it didn't seem like anyone was
interested in this :(
Previous Comments:
[2012-03-31 01:51:18] yohg...@php.net
Changed package to Scripting Engine Problem and OS is irrelevant.
Anyway, will this be supported?
[2012-03-30 15:36:18] oxygenus at gmail dot com
Description:
Parse error: syntax error, unexpected '(' in C:\phpinfo.php on line 26
26: giveArray($arrFunctions)[0]("Hello world")
Test script:
---
function($strSomeParam)
{
return $strSomeParam;
},
];
//this works
var_export(
giveArray($arrFunctions)[0]
);
//this works
var_export(
$arrFunctions[0]("Hello world")
);
//this fails compilation with syntax error
var_export(
giveArray($arrFunctions)[0]("Hello world")
);
Expected result:
Closure::__set_state(array(
))'Hello world''Hello world'
Actual result:
--
Parse error: syntax error, unexpected '(' in C:\phpinfo.php on line 26
--
Edit this bug report at https://bugs.php.net/bug.php?id=61569&edit=1
Bug #61650 [Com]: ini parser crashes when using ${xxxx} ini variables ( without apache2 )
Edit report at https://bugs.php.net/bug.php?id=61650&edit=1
ID: 61650
Comment by: ni...@php.net
Reported by:e dot tirado at meetic-corp dot com
Summary:ini parser crashes when using ${} ini variables
( without apache2 )
Status: Open
Type: Bug
Package:CGI/CLI related
Operating System: Redhat 5.8
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
I can't reproduce this:
nikic@pluto:~/dev$ cat php.ini
error_log = ${ERROR_LOG}
nikic@pluto:~/dev$ ERROR_LOG=foo php -c php.ini -i | grep error_log
error_log => foo => foo
Previous Comments:
[2012-04-06 13:02:55] e dot tirado at meetic-corp dot com
Description:
Hello,
PHP-CGI keeps crashing when loading configuration file with variable in
file. Variable are declared as ENV ones.
It doesn't crash if the variable is undefined.
I Think this bug is related to this one already corrected but only for apache2
thing : https://bugs.php.net/bug.php?id=49677
sapi_getenv (NO apache2) versus php_apache_sapi_getenv (apache2)
Test script:
---
Into php.ini file :
error_log = ${titi}
Expected result:
PHP should not crash.
Actual result:
--
(gdb) backtrace
#0 0x in ?? ()
#1 0x0063ed5a in sapi_getenv (name=0x14fcff10 "toto", name_len=) at /usr/src/debug/php-5.3.10/main/SAPI.c:947
#2 0x00664224 in zend_ini_get_var () at
/usr/src/debug/php-5.3.10/Zend/zend_ini_parser.c:225
#3 ini_parse () at /usr/src/debug/php-5.3.10/Zend/zend_ini_parser.c:1840
#4 0x0066431e in zend_parse_ini_file (fh=0x7fff6b56ab40,
unbuffered_errors=1 '\001', scanner_mode=,
ini_parser_cb=,
arg=) at
/usr/src/debug/php-5.3.10/Zend/zend_ini_parser.c:283
#5 0x0063dbe3 in php_init_config () at
/usr/src/debug/php-5.3.10/main/php_ini.c:620
#6 0x006371ca in php_module_startup (sf=,
additional_modules=0xc2ef80, num_additional_modules=1) at
/usr/src/debug/php-5.3.10/main/main.c:2012
#7 0x0070a633 in php_cgi_startup (sapi_module=0x4) at
/usr/src/debug/php-5.3.10/sapi/cgi/cgi_main.c:883
#8 0x0070ada8 in main (argc=3, argv=0x7fff6b56d3d8) at
/usr/src/debug/php-5.3.10/sapi/cgi/cgi_main.c:1623
--
Edit this bug report at https://bugs.php.net/bug.php?id=61650&edit=1
Bug #61660 [Com]: bin2hex(hex2bin($data)) != $data
Edit report at https://bugs.php.net/bug.php?id=61660&edit=1 ID: 61660 Comment by: ni...@php.net Reported by:krtek4+php at gmail dot com Summary:bin2hex(hex2bin($data)) != $data Status: Open Type: Bug Package:*General Issues Operating System: Debian Linux PHP Version:5.4.1RC1 Block user comment: N Private report: N New Comment: In my eyes hex2bin should not try to fix the corrupt data by padding it with zero. Instead it should throw a warning. The reason is simple: A padding can be either added on the left or on the right. E.g. "af52b" could be interpreted both as "0af52b" and as "af52b0". Both are valid interpretations, depending on the use case. Because of this I think a warning is more appropriate. It signals the user that the data is wrong. He can always easily fix it by adding a zero to either of the sides, whatever is more appropriate in his particular situation. Blindly adding the padding on the other hand will probably be quite unexpected. Especially when adding the 0 on the left side all the data will be shifted by 4 bits. This means that the whole data will be corrupted. All bytes will change. (Adding a padding on the right is less intrusive as it only changes one byte). Previous Comments: [2012-04-08 13:20:35] krtek4+php at gmail dot com You are right, there was a bug in the patch I sent. I updated it on github. Thanks for the comment ! [2012-04-08 12:23:32] theanomaly dot is at gmail dot com @krtek4+php I didn't mean to step on any toes, honestly. I think your patch probably looks way cleaner than mine, but when I tried compiling your patch it did not work for me. The test didn't pass. var_dump(bin2hex(hex2bin(1))); // returned string(0) "" Maybe I didn't do it right, but that's the only reason I submitted another patch after I tested again on the PHP-5.4 branch. [2012-04-08 10:08:14] krtek4+php at gmail dot com If I could intervene, my patch does exactly the same thing without adding a new test for each iteration of the loop. Mine has only one modulo (%) outside of the loop and the new test is executed only once at the first pass assuming the string is a correct hexadecimal value. Like said in your last comment, the % operation can even be optimized with a '& 1' if needed. [2012-04-08 10:01:22] larue...@php.net @theanomaly as we talked, since Rasmus said it's okey, then I have no objection. 2 suggestions : 1. use oddlen & 1 instead of oddlen % 2 2. since you cal oddlen % 2 twice, so it's better if you can use a var to hold it and it's better for you to make a pull request by yourself, let me know if you need help on that :) [2012-04-08 10:00:43] krtek4+php at gmail dot com The internal representation must always be aligned on 8 bits, thus we have no choice to pad with 0 bits at the beginning, 1000 and 1000 is the exact same value in binary and I think the actual patch is correct. The new problem is that the reverse operation, i.e. bin2hex, should remove the added 0 bit at the beginning. @theanomaly ; decbin works just fine since it returns a string composed of 0s and 1s and not a "binary value". hex2bin / bin2hex are the only function I'm aware of working this way. BTW, why did you sent another patch ? mine is doing exactly the same as yours and is working fine. 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=61660 -- Edit this bug report at https://bugs.php.net/bug.php?id=61660&edit=1
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1
ID: 54547
Comment by: ni...@php.net
Reported by:peter dot ritt at gmx dot net
Summary:wrong equality of string numbers
Status: Verified
Type: Bug
Package:Unknown/Other Function
Operating System: linux
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
@Jeff: You have to understand in PHP 1, 1.0 and "1.0" all are equivalent (in
most situations). That's by design.
E.g. GET and POST variables are always strings, even if you put numbers into
them (as per the HTTP standard). PHP obviously wants those GET/POST variables
to still be useable just like they were numbers, that's why "1" and 1 can be
used interchangeably throughout PHP.
In that context - in my eyes - this comparison also makes sense. Consider a
very similar comparison:
var_dump('0.1' == '0.1000');
What would you expect to be the output - if you remember that in PHP numeric
strings and actual numbers are interchangeable? Clearly it has to behave
exactly as if you had written:
var_dump(0.1 == 0.1000); // => bool(true)
In most cases this type of comparison is what you want and it usually works
exactly as expected.
What you see here in this issue is one of the edge cases (how often do you use
large numbers in PHP?) where it does not work well.
I hope you understand that it is not viable to remove a handy feature from PHP,
just because it fails under certain edge case conditions.
If you want to use a strict string comparison, just use ===.
Previous Comments:
[2012-04-12 13:58:53] paj...@php.net
@Jeff at bobmail dot info
that's what === is for (real comparisons without casting).
[2012-04-12 13:51:22] jabakobob at gmail dot com
The conversion to a number is necessary because programmers don't differentiate
between strings and numbers in PHP. Consider the following code:
if ($_GET["a"] == $_GET["b"]) echo "a is same as b!";
The result will be the same if the query string is ?a=1&b=1 or ?a=1&b=1.0 or ?
a=01&b=1 because PHP is loosely typed.
Internally $_GET["a"] and $_GET["b"] are both strings, but we can't do a string
comparison. If you want a string comparison, use strcmp.
[2012-04-12 13:31:42] Jeff at bobmail dot info
I'm confused as to why there is even a conversation around "should we fix this".
The data objects are strings. Sure, PHP is "loosely typed" but shouldn't it do
the comparison you tell it to do first before attempting anything else?
I agree with the previous suggestion: make it a real string comparison and drop
the type casting.
[2012-04-12 06:39:31] paj...@php.net
@a at hotmail dot com
This is not a support channel, if you need further support for the base ideas
about the loosely type nature of PHP, please ask them on one the numerous
channels.
[2012-04-12 06:39:30] paj...@php.net
@a at hotmail dot com
This is not a support channel, if you need further support for the base ideas
about the loosely type nature of PHP, please ask them on one the numerous
channels.
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=54547
--
Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1
ID: 54547
Comment by: ni...@php.net
Reported by:peter dot ritt at gmx dot net
Summary:wrong equality of string numbers
Status: Verified
Type: Bug
Package:Unknown/Other Function
Operating System: linux
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
@Jeff Please see jabakobob's comment why doing just a string comparison can be
counterproductive. Remember: PHP is mainly used around the HTTP protocol (where
everything is a string) and MySQL (where also everything is returned as a
string). So in PHP you will often deal with numbers in strings, thus they
should be handled as such.
Previous Comments:
[2012-04-12 14:02:02] Jeff at bobmail dot info
That didn't address my comment. Why wouldn't the internal implementation check
to see if the strings are the same? When doing a comparison and the internal
data type is a string, wouldn't that be faster and most correct?
In all honesty I would prefer PHP's "loosely typed" system mimic JavaScript's
in that any type can be put anywhere but the object still keeps its type
information for situations just like this.
--------
[2012-04-12 13:59:32] ni...@php.net
@Jeff: You have to understand in PHP 1, 1.0 and "1.0" all are equivalent (in
most situations). That's by design.
E.g. GET and POST variables are always strings, even if you put numbers into
them (as per the HTTP standard). PHP obviously wants those GET/POST variables
to still be useable just like they were numbers, that's why "1" and 1 can be
used interchangeably throughout PHP.
In that context - in my eyes - this comparison also makes sense. Consider a
very similar comparison:
var_dump('0.1' == '0.1000');
What would you expect to be the output - if you remember that in PHP numeric
strings and actual numbers are interchangeable? Clearly it has to behave
exactly as if you had written:
var_dump(0.1 == 0.1000); // => bool(true)
In most cases this type of comparison is what you want and it usually works
exactly as expected.
What you see here in this issue is one of the edge cases (how often do you use
large numbers in PHP?) where it does not work well.
I hope you understand that it is not viable to remove a handy feature from PHP,
just because it fails under certain edge case conditions.
If you want to use a strict string comparison, just use ===.
[2012-04-12 13:58:53] paj...@php.net
@Jeff at bobmail dot info
that's what === is for (real comparisons without casting).
[2012-04-12 13:51:22] jabakobob at gmail dot com
The conversion to a number is necessary because programmers don't differentiate
between strings and numbers in PHP. Consider the following code:
if ($_GET["a"] == $_GET["b"]) echo "a is same as b!";
The result will be the same if the query string is ?a=1&b=1 or ?a=1&b=1.0 or ?
a=01&b=1 because PHP is loosely typed.
Internally $_GET["a"] and $_GET["b"] are both strings, but we can't do a string
comparison. If you want a string comparison, use strcmp.
[2012-04-12 13:31:42] Jeff at bobmail dot info
I'm confused as to why there is even a conversation around "should we fix this".
The data objects are strings. Sure, PHP is "loosely typed" but shouldn't it do
the comparison you tell it to do first before attempting anything else?
I agree with the previous suggestion: make it a real string comparison and drop
the type casting.
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=54547
--
Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
Req #46189 [Com]: php needs a compile-time include/require like #include
Edit report at https://bugs.php.net/bug.php?id=46189&edit=1
ID: 46189
Comment by: ni...@php.net
Reported by:noah at missionecommerce dot com
Summary:php needs a compile-time include/require like
#include
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Linux
PHP Version:5.2.6
Block user comment: N
Private report: N
New Comment:
How about putting the code into a function and including it just once?
Previous Comments:
[2008-09-27 10:12:35] noah at missionecommerce dot com
Description:
Using include/require in a loop causes horrible preformance, because of the
additional stat, file read, and opt-code compile on every loop iteration.
PHP really needs a method to do compile-time includes/requires as well as the
current run-time include/require.
I would like to be able to do #include like in C and have the compiler insert
the contents of the file into the script BEFORE compilation.
This shouldn't be a complicated feature addition, and it would make life alot
easier when developing with large projects with alot of reusable code.
Reproduce code:
---
for( $i = 0; $i < 1000; $i ++ ) {
// I want run this code by including the file
// But this code is not appropriate to make a function for
// And its very long, so I dont just want to paste the code inside
// this loop because it makes developement more confusing
include '/www/some_code_snippet.php';
}
Expected result:
Although I knew include was a run-time event, I was hoping
behavior to #include in C.
Actual result:
--
Tracing the code, I found it produced 1000 file stats, 1000 file reads, and
1000 opt-code compiles
--
Edit this bug report at https://bugs.php.net/bug.php?id=46189&edit=1
Bug #64248 [Com]: Strange parse error when using language construct in for
Edit report at https://bugs.php.net/bug.php?id=64248&edit=1
ID: 64248
Comment by: ni...@php.net
Reported by:bobwei9 at hotmail dot com
Summary:Strange parse error when using language construct in
for
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Irrelevant (OS X 10.8)
PHP Version:master-Git-2013-02-19 (Git)
Block user comment: N
Private report: N
New Comment:
Imho unset() should stay as it is, a statement. It has no meaningful return
value and does not really benefit much from allowing expression use.
If you want to perform some complex operation in the last for-loop expressions,
then you should just put it into the body:
for ($i = 'A'; ++$i < $max;) {
var_dump($$i);
unset($$i);
}
The last for-loop expression is usually used for variable increments or other
simple expressions. It's not there to inline your whole loop body. If you want
to put your unset() call in there, why not move the var_dump in there too?
for ($i = 'A'; ++$i < $max; var_dump($$i), unset($$i));
Look, it's shorter!
Just my opinion on this.
Previous Comments:
[2013-02-20 08:06:27] bobwei9 at hotmail dot com
It is a language construct, yes. But this seems to be a design mistake which
should not be.
As in the pull request proposed: "an idea would be to make unset return true
if the variable has
existed else false?"
Does this need a RFC or a discussion on the internals?
[2013-02-19 23:46:00] 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
unset() jsut as many other language constructs has no return value and is no
expression. for expects expressions. This construct makes sense only in very
few cases, even though it might make the language a tiny bit simpler (less
exceptions) it is not worth changing the language ... (changing language has
effects for the whole environment, from IDEs to code analyzers, to ...)
[2013-02-19 21:05:21] bobwei9 at hotmail dot com
Oops, the expected result should be a notice and $max should be 'A' in the test
script...
[2013-02-19 21:03:57] bobwei9 at hotmail dot com
Description:
For example unsetting a var in the third part of a for-loop throws an E_PARSE
error.
Test script:
---
php -r '
$A = [1];
$B = [1,7];
$max = 'B';
for ($i='A'; ++$i<$max; unset($$i))
var_dump($$i);'
Expected result:
array(1) {
[0]=>
int(1)
}
array(2) {
[0]=>
int(1)
[1]=>
int(7)
}
Actual result:
--
PHP Parse error: syntax error, unexpected 'unset' (T_UNSET), expecting ')' in
Command line code on line 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=64248&edit=1
Bug #62634 [Com]: Incorrect serialization with circular references
Edit report at https://bugs.php.net/bug.php?id=62634&edit=1
ID: 62634
Comment by: ni...@php.net
Reported by:phplists at stanvassilev dot com
Summary:Incorrect serialization with circular references
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Any
PHP Version:5.4.5
Block user comment: N
Private report: N
New Comment:
The reason this happens is that serialize accepts by value, and as such the
outer array will be a separated and will be different from the one that is
references from within the array.
This can be fixed by marking the serialize argument as ZEND_SEND_PREFER_REF.
Not sure if this should be done or not.
Previous Comments:
[2012-07-25 13:25:23] f...@php.net
Maybe related to https://bugs.php.net/bug.php?id=62189
[2012-07-22 21:58:45] phplists at stanvassilev dot com
There's a small error in my code example, please replace this line:
$duplicate = unserialize(serialize($x));
With this line:
$duplicate = unserialize(serialize($original));
[2012-07-22 21:54:54] phplists at stanvassilev dot com
Description:
The documentation says references and circular references should serialize
properly. I've found that serialize would first copy the referenced variable,
before detecting the reference.
This not only doubles the serialized output, but produced incorrect copy when
unserialized.
Test script:
---
$original = array('hello');
$original[] = & $original;
echo serialize($original);
// Output (notice the duplication):
// "a:2:{i:0;s:5:"hello";i:1;a:2:{i:0;s:5:"hello";i:1;R:3;}}"
$duplicate = unserialize(serialize($x));
// Now I modify both the original and the duplicate in an identical way.
// But I get different results, because the duplicate points to a copy of
// itself, instead of pointing to itself.
$original[0] = 'world';
$duplicate[0] = 'world';
var_dump($original);
// Produces (notice it says "world" both times, i.e. it points to itself):
// array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5) "world"
[1]=> *RECURSION* } }
var_dump($duplicate);
// Produces (notice the second time it says "hello" i.e. it's a copy):
// array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5) "hello"
[1]=> *RECURSION* } }
Expected result:
There should be NO copies of "hello" left:
array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5) "world"
[1]=>
*RECURSION* } }
There should be NO duplication in the serialized output:
"a:2:{i:0;s:5:"hello";i:1;???;}" (Fill-in the "???" appropriately :) )
Actual result:
--
A copy of "hello" is left:
array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5) "hello"
[1]=>
*RECURSION* } }
There is duplication in the serialized output:
"a:2:{i:0;s:5:"hello";i:1;a:2:{i:0;s:5:"hello";i:1;R:3;}}"
--
Edit this bug report at https://bugs.php.net/bug.php?id=62634&edit=1
Req #64454 [Com]: It is possible to directly call the magic method "__construct".
Edit report at https://bugs.php.net/bug.php?id=64454&edit=1 ID: 64454 Comment by: ni...@php.net Reported by:wolters dot fl at gmail dot com Summary:It is possible to directly call the magic method "__construct". Status: Wont fix Type: Feature/Change Request Package:Class/Object related Operating System: Microsoft Windows Version 6.2.9 PHP Version:5.4.13 Block user comment: N Private report: N New Comment: Additionally to what laruence said, one should also point out that __construct is quite commonly called directly in the form of parent::__construct(). Previous Comments: [2013-03-22 04:18:32] larue...@php.net PHP's __construct, actually, is not creating object, it decorate the object after it was created. so, even you directly call to $obj->__construct, then no new instance was create. so a workaround is you can exam some property you set to see whether that is a double constructing or not. thanks [2013-03-19 12:45:54] wolters dot fl at gmail dot com Description: It is possible to directly call the magic method "__construct". This should NOT be possible, since one cannot create immutable objects with the current behaviour. In addition, a direct call to the magic method "__clone" is not possible and raises an "\E_FATAL". Both magic methods deal with object creation, so the behaviour is inconsistent between them. I am using "php-5.4.13-nts-Win32-VC9-x86" on Microsoft Windows Version 6.2.9 x64(Windows 8 64 bit). Test script: --- https://gist.github.com/FlorianWolters/5195734 Expected result: The method call: $example->__construct(); should raise an "\E_FATAL" with the following message: "Cannot call __construct() method on objects - use 'new ' instead in [...] on line 21" -- Edit this bug report at https://bugs.php.net/bug.php?id=64454&edit=1
Req #64454 [Com]: It is possible to directly call the magic method "__construct".
Edit report at https://bugs.php.net/bug.php?id=64454&edit=1 ID: 64454 Comment by: ni...@php.net Reported by:wolters dot fl at gmail dot com Summary:It is possible to directly call the magic method "__construct". Status: Wont fix Type: Feature/Change Request Package:Class/Object related Operating System: Microsoft Windows Version 6.2.9 PHP Version:5.4.13 Block user comment: N Private report: N New Comment: 1. parent::__construct() is not a static method call, its a scoped call. It only says: Do $this->__construct() in the "parent" context. 2. Could you explain why it is a problem? What issues are there with calling __construct() from outside the class? I don't see any. I don't see much use either. One possible use would be calling it in a context where the constructor is not called by itself, e.g. one could call __construct() after an unserialization or something. Really, I don't get why you want to forbid this. We don't usually prohibit direct calls to magic methods and I don't see why we should do so in this particular instance. Quite honestly, I more wonder why the call to __clone() is not allowed. Previous Comments: [2013-03-22 16:19:05] wolters dot fl at gmail dot com Yes, I do understand that "__construct" is an interceptor method and can be called from a subclass directly via "parent::__construct", but: 1. "parent::__construct" is a "static" method call which can occur inside of a class only. 2. The problem is, that it is possible to call "$obj->__construct" from outside a class. I could understand the behaviour if the call would be allowed from the inside of a class only. Imho, calling "__construct" directly should ONLY be possible from the INSIDE of a class. Plus, such a call MUST be STATIC (otherwise a PHP error is raised). >From a clients PoV, __construct is a member method (similar to __clone): * __clone is invoked via the "clone" operator. * __construct is invoked via the "new" operator. I don't see the reason, why there is a difference in that behaviour. I do not know much about the internals (C code) of the interceptor methods, but from the clients PoV these distinctions in behaviour are confusing. PS: I also updated my example at https://gist.github.com/FlorianWolters/5195734 to emphasize this. [2013-03-22 07:03:54] ni...@php.net Additionally to what laruence said, one should also point out that __construct is quite commonly called directly in the form of parent::__construct(). [2013-03-22 04:18:32] larue...@php.net PHP's __construct, actually, is not creating object, it decorate the object after it was created. so, even you directly call to $obj->__construct, then no new instance was create. so a workaround is you can exam some property you set to see whether that is a double constructing or not. thanks [2013-03-19 12:45:54] wolters dot fl at gmail dot com Description: It is possible to directly call the magic method "__construct". This should NOT be possible, since one cannot create immutable objects with the current behaviour. In addition, a direct call to the magic method "__clone" is not possible and raises an "\E_FATAL". Both magic methods deal with object creation, so the behaviour is inconsistent between them. I am using "php-5.4.13-nts-Win32-VC9-x86" on Microsoft Windows Version 6.2.9 x64(Windows 8 64 bit). Test script: --- https://gist.github.com/FlorianWolters/5195734 Expected result: The method call: $example->__construct(); should raise an "\E_FATAL" with the following message: "Cannot call __construct() method on objects - use 'new ' instead in [...] on line 21" -- Edit this bug report at https://bugs.php.net/bug.php?id=64454&edit=1
Bug #62820 [Com]: mysqlnd API incompatability breaks PDOStatement->nextRowset()
Edit report at https://bugs.php.net/bug.php?id=62820&edit=1
ID: 62820
Comment by: ni...@php.net
Reported by: ni...@php.net
Summary:mysqlnd API incompatability breaks
PDOStatement->nextRowset()
Status: Assigned
Type: Bug
Package:PDO related
PHP Version:master-Git-2012-08-14 (Git)
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Just looked at the code again, what I said above is wrong. The code checks
mysql_more_results() before
(http://lxr.php.net/xref/PHP_TRUNK/ext/pdo_mysql/mysql_statement.c#414), so it
should not be related to the return value of mysql_next_result(). Something
else is wrong.
Previous Comments:
[2012-08-14 18:29:18] ni...@php.net
Related bug report: https://bugs.php.net/bug.php?id=62803
[2012-08-14 18:28:31] ni...@php.net
Description:
When the mysqlnd driver is used PDOStatement->nextRowset() does not return
bool(false) when there are no more result sets. This causes several test
failures, which all have a diff looking similar to this:
008+
009+ Warning: PDOStatement::fetchAll(): SQLSTATE[HY000]: General error in
%s/bug_41997.php on line 11
010+ array(0) {
011+ }
This can be traced down to mysql_next_result() returning 0 instead of -1 in
http://lxr.php.net/xref/PHP_TRUNK/ext/pdo_mysql/mysql_statement.c#415.
The reason is that (when using mysqlnd) mysql_next_result is aliased to
mysqlnd_next_result, but both have different APIs: The mysqlnd_ version only
returns PASS = 0 or FAIL = 1, whereas the mysql_ version returns -1 if the call
worked, but there were no more resultsets.
This is documented at
http://dev.mysql.com/doc/refman/5.0/en/mysql-next-result.html in the "Return
Values" section. The default mysqlnd next_result implementation is here:
http://lxr.php.net/xref/PHP_TRUNK/ext/mysqlnd/mysqlnd.c#2100.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62820&edit=1
Bug #64518 [Com]: optimisation for "for ($i=0; $i
Edit report at https://bugs.php.net/bug.php?id=64518&edit=1
ID: 64518
Comment by: ni...@php.net
Reported by:php at richardneill dot org
Summary:optimisation for "for ($i=0; $i The issue you are seeing is that `global $data` is a by-reference fetch
> (unlike `$data = $GLOBALS['data']`, which is by-value). The by-ref pass
> prevents us from doing a copy-on-write optimization when passing the array to
> the by-value count() function, so the array has to be copied every single
> time.
Thanks for the explanation. That makes some sense as an explanation. However,
it also implies that use of "$GLOBALS['var']" is always faster, sometimes much
faster, than "global $var". If this is true, might I suggest that this is a
documentation issue that should be addressed?
--------
[2013-03-26 13:34:40] ni...@php.net
The issue you are seeing is that `global $data` is a by-reference fetch (unlike
`$data = $GLOBALS['data']`, which is by-value). The by-ref pass prevents us
from doing a copy-on-write optimization when passing the array to the by-value
count() function, so the array has to be copied every single time.
The specific count() case is something we could optimize by adding a read-only
passing mode for function arguments (that never separates zvals). As that is
something that's also useful for a few other things, it might well be worth
doing.
[2013-03-26 06:34:44] php at richardneill dot org
... and getting closer to the source of the problem...
function a(){ //about 1400 us
global $data;
$n = $data;
}
function b(){ //much much quicker: about 18us
$n = $GLOBALS['data'];
}
Something is definitely wrong here, that makes "global" so much slower than
$GLOBALS.
Also, this isn't a read-only optimisation which makes b() much quicker than
a();
it still applies even when we want to copy back into the global scope.
Consider:
function x(){
$n = $GLOBALS['data'];
$GLOBALS['data'] = count($n);
}
and x() is always about as fast as b().
A secondary problem: if x() is rewritten as:
function y(){
$GLOBALS['data'] = count($GLOBALS['data']);
}
then it can be either fast or slow depending on whether other function calls
contain "global $data" or not.
[2013-03-26 06:09:30] php at richardneill dot org
Here's a simpler test case. The problem is actually that accessing global
variables from functions is much slower than local variables (and I was seeing
this exacerbated by looping over them with count).
Note that passing the data directly as a function argument is much faster than
passing it as a global variable - this seems to me to be the root of the
problem. i.e.
function ($a,$b,$c,$large_array){
//do stuff - this is fast.
}
function ($a,$b,$c){
global $large_array
//do stuff - this is SLOW.
}
#!/usr/bin/php -ddisplay_errors=E_ALL
[2013-03-26 05:17:44] php at richardneill dot org
Description:
If an array is counted inside a for-loop, this is normally slightly inefficient.
$n = count ($array); //[1] optimised and a bit faster.
for ($i=0; $i< $n;$i++){
//do stuff
}
for ($i=0; $i
Expected result:
All 4 ways of summing this array should run in similar amounts of time (a few
milliseconds).
But actually add_slow() is 3900 times slower.
Actual result:
--
This demonstrates the problem with counting global arrays inside loops inside
functions.
Calling add_slow()...
Total (slow) is 49995000.
Finished in 7.86 seconds.
Calling add_fast()...
Total (fast) is 49995000.
Finished in 0.002 seconds.
Calling add_local()...
Total (local) is 49995000.
Finished in 0.006 seconds.
Not using a function...
Total (main loop) is 49995000.
Finished in 0.002 seconds.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64518&edit=1
[PHP-BUG] Bug #64544 [NEW]: Valgrind warnings after using putenv (due to processtitle)
From: nikic Operating system: PHP version: 5.5.0beta1 Package: CGI/CLI related Bug Type: Bug Bug description:Valgrind warnings after using putenv (due to processtitle) Description: Due to the changes introduced by https://wiki.php.net/rfc/cli_process_title running https://bugs.php.net/bug.php?id=64544&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64544&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64544&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64544&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64544&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64544&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64544&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64544&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64544&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64544&r=support Expected behavior: https://bugs.php.net/fix.php?id=64544&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64544&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64544&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64544&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64544&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64544&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64544&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64544&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64544&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64544&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64544&r=mysqlcfg
Bug #64545 [Com]: PHP Error in ef93a93ee21bce9218188
Edit report at https://bugs.php.net/bug.php?id=64545&edit=1 ID: 64545 Comment by: ni...@php.net Reported by:bobwei9 at hotmail dot com Summary:PHP Error in ef93a93ee21bce9218188 Status: Closed Type: Bug Package:Testing related Operating System: Irrelevant PHP Version:master-Git-2013-03-28 (Git) Assigned To:laruence Block user comment: N Private report: N New Comment: Thanks, fixed on 5.4 too. Previous Comments: [2013-03-28 17:32:16] bobwei9 at hotmail dot com Please fix it in the PHP 5.4 branch too. [2013-03-28 17:24:52] ni...@php.net Automatic comment on behalf of nikic Revision: http://git.php.net/?p=php-src.git;a=commit;h=b1a6a1703910d77ef7932cd4b03a36a4dbabc917 Log: Fix Bug #64545:PHP Error in ef93a93ee21bce9218188 [2013-03-28 17:15:26] bobwei9 at hotmail dot com Description: http://git.php.net/?p=php- src.git;a=commitdiff;h=ef93a93ee21bce9218188d3f037cf55c5d2ae452 die is not a language construct, but a normal function. The skipif code here produces a parse error. -- Edit this bug report at https://bugs.php.net/bug.php?id=64545&edit=1
Bug #64555 [Com]: foreach no longer copies keys if they seem to be interned
Edit report at https://bugs.php.net/bug.php?id=64555&edit=1
ID: 64555
Comment by: ni...@php.net
Reported by:ar...@php.net
Summary:foreach no longer copies keys if they seem to be
interned
Status: Closed
Type: Bug
Package:Scripting Engine problem
PHP Version:5.5.0beta1
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
I went with always copying the key for now. Doing the copy in get_object_vars
might be better, but would require a more thorough review of where else this
could go wrong.
Previous Comments:
[2013-04-03 18:33:42] ni...@php.net
Automatic comment on behalf of nikic
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=1f34ccbe34783f5671bc2a68e7299cea7493c82b
Log: Fix bug #64555: foreach no longer copies keys if they are interned
[2013-03-31 11:24:50] ar...@php.net
N.B. This indirectly causes a fatal error when using ZF1 forms so the impact is
very high.
[2013-03-31 11:21:13] ar...@php.net
Description:
Foreach used to always copy string keys:
key_type = zend_hash_get_current_key_ex(fe_ht, &str_key, &str_key_len,
&int_key, 1, NULL);
Since fcc6611de9054327441786e52444b5f8eecdd525 it instead uses:
zend_hash_get_current_key_zval(fe_ht, key);
This only copies string keys if IS_INTERNED(), however in some cases (at least
in get_object_vars() like in the test script) the key name is an unmangled
property name which is *within* an interned string. So IS_INTERNED is true but
INTERNED_LEN and INTERNED_HASH are nonsense.
The later unset and assignment in the test script use the nonsense
INTERNED_HASH.
The simple fix is to make get_object_vars() copy the property names (as in the
attached patch) but it's quite possible that other code has been broken in the
same way, so the safer fix might be to force the copy again.
Test script:
---
https://gist.github.com/arraypad/5280321
Expected result:
Unsetting: unsetme
Changing: keepme
array(1) {
["keepme"]=>
int(43)
}
array(1) {
[0]=>
string(6) "keepme"
}
Actual result:
--
Unsetting: unsetme
Changing: keepme
array(3) {
["unsetme"]=>
int(1)
["keepme"]=>
int(43)
["keepme"]=>
int(42)
}
array(3) {
[0]=>
string(7) "unsetme"
[1]=>
string(6) "keepme"
[2]=>
string(6) "keepme"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=64555&edit=1
Bug #53405 [Com]: accessing the iterator inside a foreach loop leads to strange results
Edit report at https://bugs.php.net/bug.php?id=53405&edit=1
ID: 53405
Comment by: ni...@php.net
Reported by:jpa...@php.net
Summary:accessing the iterator inside a foreach loop leads
to strange results
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: *nix
PHP Version:5.3.3
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
Here is an initial patch:
https://github.com/nikic/php-src/commit/185c7fae3a3d7a90693c24726a8f2685b3751464
Not yet quite done though.
Previous Comments:
[2013-04-09 18:05:02] ni...@php.net
Taking over this bug. I have an alternative foreach implementation that does
not rely on the IAP and as such fixes this (and other) problems. I'll try to
clean it up sometime soon.
[2013-04-09 14:28:36] jpa...@php.net
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.
Ok, I'm gonna add a doc hint.
[2013-04-09 10:10:25] dmi...@php.net
First off all mixing foreach() and reset/next/current is not a good idea.
In general the value of internal iterator pointer is undefined when using
foreach().
At second "false" is more expected value, than "a".
The value "b" may be explained as well. The current() call in the foreach loop
separates the value of variable $a from the array used by foreach loop. So we
got two copies of arrays with different iterator positions.
I don't think we should try to fix it. It's better to add the note into
documentation about undefined behaviour in case of mixing foreach and
reset/next/current.
[2013-04-08 23:39:38] chris at clowerweb dot com
I actually experienced something last night during Wordpress development that I
believe to be related to this.
Somehow the foreach loop was manipulating a $post (not $posts) variable in
another
part of the script, causing post pages to display incorrect content.
[2010-11-25 18:38:12] jpa...@php.net
Description:
foreach() is supposed to work on a copy of the iternal iterator.
However, manipulating the iterator inside the foreach loop leads to very
strange results.
-> Also try to print the result of current() inside the foreach loop in the 3
use cases provided. You'll see that the iterator is some kind of manipulated by
foreach
Test script:
---
$a = range('a','d');
foreach ($a as $v) { }
var_dump(current($a));
$a = range('a','d');
foreach ($a as $v) { current($a); }
var_dump(current($a));
$a = range('a','d');
foreach ($a as &$v) { current($a); }
var_dump(current($a));
Expected result:
'a'
'a'
'a'
Actual result:
--
false
'b'
false
--
Edit this bug report at https://bugs.php.net/bug.php?id=53405&edit=1
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837&edit=1
ID: 40837
Comment by: ni...@php.net
Reported by:nick dot telford at gmail dot com
Summary:static and non-static functions can't have the same
name
Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: Irrelevant
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
We *can not* have static and non-static methods with the same name. This is
*not* just a backwards compatibility concern.
I think the issue here is that you got the meaning of the :: operator wrong. ::
is not a "static access operator", it's a "scope resolution operator". It calls
a method (or accesses a property) in a certain scope.
E.g. Foo::bar() calls the method bar() in the scope of class Foo. bar() here
can be any method.
A "static" method just means that the method does not need $this. The
Foo::bar() call will only work if
a) the method is static or
b) the method is non-static and we have a $this.
The distinction between "static access operator" and "scope resolution
operator" is important and helps you understand why some things are as they
are. For example, if you want to access a parent method, then what do you write?
parent::foo(). This means that you call foo() in the parent scope.
I get that people might argue whether "calling non-static methods with ::" is
useful in the general case, but calling parent methods is something everybody
should understand and find useful. And using that example it's also easy to see
why you couldn't have the same static and non-static method. Consider this
small example:
class A {
public function foo() { echo 'non-static'; }
public static function foo() { echo 'static'; }
}
class B {
public function bar() { echo parent::foo(); }
}
(new B)->bar(); // What do you get?
Allowing static and non-static methods of the same name would require us to
completely change the concept of scope-resolution and find a different way to
call parent methods etc.
So, just to say it again: Removing "::"-calls to non-static methods is *not*
just a backwards compatibility issue, it would also cause problems with other,
currently used and encouraged language features.
Another thing that might help the understanding (apart from interpreting :: as
scope-resolution) is not seeing static and non-static methods as distinct
method types. Rather they are the same and "static" is just another method
modifier like "public" or "final":
You probably wouldn't ask to have "an abstract method and a final method of the
same name", right? Asking for a non-static and static method of the same name
makes similarly little sense. "static" just means "doesn't need $this" and
nothing more.
On a related note, this "static" modifier is also available for closures (i.e.
you can write "$foo = static function() { ... }") and also means the same
there, that the closure does not need $this. Prefixing a closure with "static"
does not make it some kind of wholly different function type, it's just a
modifier. Same for the static methods ;)
I hope things are a bit clearer now.
Previous Comments:
[2013-04-21 05:30:23] dmittner at llnw dot com
I've got to add my vote to this feature.
My use case consists of data validation methods. If called statically the
validation tests are limited to things like string length, contents, etc. If
called on an object it would include those tests (probably calling the static
form of itself) and also comparative tests to other object conditions.
I sympathize with backwards compatibility but sometimes you have to push
forward. Case and point, some people I know are working with a Java-based
system
that doesn't support Java 7, so when building new servers they have to
explicitly install an older version. Cutting a line between major PHP versions
seems similarly viable.
I'd also cite Magic Quotes which are completely removed in 5.4, which could
similarly break older PHP4 compatibility. The precedent is set.
Failing all that, how about a configuration option?
[2012-11-20 02:13:10] capitaine dot gloumi at gmail dot com
The "backward compatibility" should set to deprecated any static call of object
method, and use it IF NO static method with the same name exist.
I use static method and object method with same name in lot of paterns, it's
useful in lot of case.
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837&edit=1 ID: 40837 Comment by: ni...@php.net Reported by:nick dot telford at gmail dot com Summary:static and non-static functions can't have the same name Status: Not a bug Type: Bug Package:Class/Object related Operating System: Irrelevant PHP Version:5.2.1 Block user comment: N Private report: N New Comment: @dmittner: > ":: is not a "static access operator", it's a "scope resolution operator". It > calls a method (or accesses a property) in a certain scope." > > Conceptually that one operator is trying to do too much. That "certain scope" > it's trying to use isn't chosen by the programmer; it's chosen by the > context; by where it's being used. That's presumptuous and an unnecessary > limitation. Maybe I didn't phrase that well enough. By "in a certain scope" I meant the class before the :: operator. In Foo::bar() the bar() method is called in the Foo scope. So, as you can see the scope *is* chosen by the programmer and no presumption takes place. > "::" is (AFAIK) the only way to access specifically static resources in one > context, but then is also used to reference the resources of special names in > other contexts. Again, this might be a misunderstanding. The scope-resolution behavior is *not* restricted to special names. It's not just about parent::foo() [and self::foo() and static::foo()], I just used that as an example as it is the most commonly used. You can do a scope-resolution call on any class in the inheritance hierarchy (e.g. a grandparent). Actually right now you could even do the call to using a scope that is outside the hierarchy, but thankfully we'll be removing that anti-feature in the next version. What we could obviously do - as you suggest - is strictly decouple scoped static method calls and scoped non-static method calls, by having a Foo::bar() syntax and a Foo->bar() syntax (e.g. parent->bar()). In my eyes that's a bad idea. We'd be adding a lot of new complexity (by making static methods *actually* different and not just a modifier of normal methods) only for the very small gain of having statics and non-statics of the same name. By the way, I just looked at a few other languages and it seems like nearly all went the same way as PHP. C++ doesn't allow it, C# doesn't allow it, Java doesn't allow it. Python doesn't really have statics, but it has the @staticmethod decorator and with that it's obviously not allowed either. The only language I looked at and which *does* support this is Ruby. So, I really don't see a solid case for this feature request. Previous Comments: [2013-04-21 21:47:20] billco at fnarg dot com My thoughts echo those of dmittner, while I think we all acknowledge the need for parent::method() functionality, I don't see why that small detail should invalidate this popular feature request. This seems like a limitation borrowed from C++, where it was a necessary evil of supporting multiple inheritance. PHP does not have MI and thus there was never a need for such a contrived "scope resolution" operator when something like Java's "super" would have sufficed. I can recognize that its usage dates back to the very beginning of PHP OOP, and it would be problematic to change the :: operator with all the existing code out there. Why can't we choose a new operator for pure static calls and get on with it ? It sounds like that would allow same-named static methods without ambiguity, while allowing the :: operator to continue as-is. [2013-04-21 18:57:01] dmittner at llnw dot com @ni...@php.net: While what you write is all technically correct, I think it comes down to this being the problem: ":: is not a "static access operator", it's a "scope resolution operator". It calls a method (or accesses a property) in a certain scope." Conceptually that one operator is trying to do too much. That "certain scope" it's trying to use isn't chosen by the programmer; it's chosen by the context; by where it's being used. That's presumptuous and an unnecessary limitation. "::" is (AFAIK) the only way to access specifically static resources in one context, but then is also used to reference the resources of special names in other contexts. Clearly people want to be able to call the same method name in both an object and static scope. It's the same reason people like function overloading: they
Req #64639 [Com]: Add third parameter to nl2br
Edit report at https://bugs.php.net/bug.php?id=64639&edit=1
ID: 64639
Comment by: ni...@php.net
Reported by:valentiny510 at yahoo dot es
Summary:Add third parameter to nl2br
Status: Open
Type: Feature/Change Request
Package:*General Issues
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
In my eyes this is an unnecessary change. nl2br handles the common case, where
you want to have linebreaks displayed and have the code nicely formatted at the
same time. This is what nl2br does and I don't think it need to do any more.
I don't see why we should add support for incorrect usages of the function
inside . And in any case, if you should have need for this (for whatever
odd reason), then it is trivial to write yourself. Quite honestly I think that
preg_replace('#([\r?\n]+)#', '', $string) is a good bit clearer than
nl2br($string, false, true). That's just too many unclear boolean parameters.
Previous Comments:
[2013-05-03 07:01:13] octavianmarinescu at tavi dot ro
yes would be a shorter and more elegant solution
nl2br($str, false, true);
nice and clean..
[2013-04-17 19:44:35] krak...@php.net
The following patch has been added/updated:
Patch Name: nl2br_additional_parameter
Revision: 1366227875
URL:
https://bugs.php.net/patch-display.php?bug=64639&patch=nl2br_additional_parameter&revision=1366227875
[2013-04-12 02:12:27] valentiny510 at yahoo dot es
Description:
The name "nl2br" for somebody who doesn't know php very well, suggest that
actually replace "nl" with "br" but is not true. The name of the function
function should be "nl2nl+br"
I think it should have a third parameter like $replace, and actually Replace
the nl with br
I have some clients who used this function inside pre with horrible result.
Anyway, I think it will be more usefull this
nl2br ($string, true/false, $replace = true/false)
than
preg_replace('#([\r?\n]+)#', '', $string) or
str_replace(array("\r\n", "\r", "\n"), '', $string)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64639&edit=1
Bug #39349 [Com]: Core dump on preg_replace
Edit report at https://bugs.php.net/bug.php?id=39349&edit=1 ID: 39349 Comment by: ni...@php.net Reported by:nikolas dot hagelstein at gmail dot com Summary:Core dump on preg_replace Status: Not a bug Type: Bug Package:PCRE related Operating System: Netbsd 3.0.1 PHP Version:5.2.0 Assigned To:andrei Block user comment: N Private report: N New Comment: @tsteiner: I'm pretty sure that this option was considered, but was found to carry a performance penalty. Would be nice to get some data on this. Previous Comments: [2013-05-08 20:36:54] tsteiner at nerdclub dot net I've uploaded a patch that will disable using the stack for recursion when building PCRE with the included library source. I've found that this completely eliminates segfaults when using PCRE functions on long strings. [2006-12-01 21:37:36] nikolas dot hagelstein at gmail dot com A stack overflow shouldnt cause a segfault. [2006-12-01 20:25:11] nlop...@php.net no bug here. just a stack overflow, which is avoidable by tweaking the new ini options and/or increasing the stack size. [2006-11-12 19:03:04] tony2...@php.net Yes, endless recursion most likely results in a segfault and this is expected. [2006-11-12 15:15:26] nikolas dot hagelstein at gmail dot com This seems to be stack overflow related in general: do_something(); } } $i=0; $x = new Foo(); $x ->do_something(); ?> Endless recursion results in stack overflow which throws a segmentation fault. Probably libc os related. 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=39349 -- Edit this bug report at https://bugs.php.net/bug.php?id=39349&edit=1
Req #64185 [Com]: is_callable does not check syntax
Edit report at https://bugs.php.net/bug.php?id=64185&edit=1 ID: 64185 Comment by: ni...@php.net Reported by:hanskrentel at yahoo dot de Summary:is_callable does not check syntax Status: Wont fix Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.4.11 Block user comment: N Private report: N New Comment: I just remembered that as of 5.4 you can actually create classes with arbitrary names from userland using class_alias. So that makes the second point moot too. Previous Comments: [2013-02-13 19:52:48] ni...@php.net Agree with what johannes said, marking as wontfix. [2013-02-13 14:40:45] johan...@php.net Even with classes such names could - theoretically - exist due to weird (3rd party) extensions etc. (i hope nobody does, but there's nothing stopping one) So "syntax" in this case does not mean "one could use those names in syntactically correct PHP code" but "the overall structure matches something that might be used in a lookup" [2013-02-10 17:04:38] hanskrentel at yahoo dot de NikiC was so friendly to just remind me that checking for the method name *is* limited because of __call and __callStatic (basically everything for a method name works, including a zero-length string). So this feature request is actually more about the classname validation then the method name validation. [2013-02-10 16:04:21] hanskrentel at yahoo dot de Description: Using is_callable with the syntax_only parameter set to true does actually *not* check the syntax, for example of a valid classname or FQCN. Also not for the method name. My feature request is, that it will always check those strings according to the rules set in the PHP parser of the same PHP version the function ships with so that it can be used to validate PHP syntax as well. Same for calls with :: for static class name method calls. Test script: --- var_dump(is_callable(['', ''], true)); var_dump(is_callable(['', 'method'], true)); var_dump(is_callable(['0', 'method'], true)); var_dump(is_callable(['0\\foo', 'method'], true)); var_dump(is_callable(['\\0\\foo', 'method'], true)); Expected result: bool(false) bool(false) bool(false) bool(false) bool(false) Actual result: -- bool(true) bool(true) bool(true) bool(true) bool(true) -- Edit this bug report at https://bugs.php.net/bug.php?id=64185&edit=1
Req #64818 [Com]: array_get
Edit report at https://bugs.php.net/bug.php?id=64818&edit=1 ID: 64818 Comment by: ni...@php.net Reported by:mario dot dweller at seznam dot cz Summary:array_get Status: Wont fix Type: Feature/Change Request Package:Arrays related PHP Version:Irrelevant Block user comment: N Private report: N New Comment: @Pierre: isset($array['key1']['key2']) ?: NULL is the same as isset($array['key1']['key2']) ? isset($array['key1']['key2']) : NULL is the same as "true" if the key exists, "null" if it doesn't. That's not what this req is about. Previous Comments: [2013-05-12 10:53:39] paj...@php.net $val = isset($array['key1']['key2']) ?: NULL; We already have an operator for that ($v = (iftrue) ?: defaultvalue). Operators are also much more efficient than a function call. [2013-05-12 10:37:02] mario dot dweller at seznam dot cz fl at nyggen dot com: I know this is possible. But i don't like suppressing warning in this situation. And @$array['key1']['key2'] ?: 'Key not found' And the valid value could be false/0/""/"0"/[]. [2013-05-12 06:41:16] fl at nyggen dot com You could just write: @$array['key1']['key2']; Which will give you the same result. @$array['key1']['key2'] ?: 'Key not found' [2013-05-11 17:07:24] mario dot dweller at seznam dot cz Description: What about to create a new array function array_get? When we have a function like array_column... function array_get(array $array, $key, $default = null) Something like this. http://api.nette.org/2.0/source-Utils.Arrays.php.html#36-53 Ofc i can use that Arrays::get method or i can create my own function/static method. But it has a performance overhead for quite a common thing which should be as fast as it's possible. I hate typing this. isset($array['key1']['key2']) ? $array['key1']['key2'] : null; This looks better. array_get($array, ['key1', 'key2'], null) or just array_get($array, 'key') -- Edit this bug report at https://bugs.php.net/bug.php?id=64818&edit=1
Req #64854 [Com]: array_key_exists( array('key1', 'key2', 'key3'), $array);
Edit report at https://bugs.php.net/bug.php?id=64854&edit=1
ID: 64854
Comment by: ni...@php.net
Reported by:bensor987 at neuf dot fr
Summary:array_key_exists( array('key1', 'key2', 'key3'),
$array);
Status: Wont fix
Type: Feature/Change Request
Package:Arrays related
Operating System: All
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Sure, that's why I said that it only applies to arrays "with no odd null-value
usages". You used $_GET and $_POST as examples in your FR, both of which can
only contain string and array values (no nulls). Thus for them multi-parameter
isset() is sufficient. That's why I asked whether you have any other particular
use cases in mind.
Previous Comments:
[2013-05-16 11:23:15] bensor987 at neuf dot fr
isset() doesn't behave like array_key_exists(). It will sometimes return false
when the key exists. I want the result to be as realist as possible.
Example :
$array = array( 'key_null' => NULL );
var_dump( isset( $array['key_null'] ) );
var_dump( array_key_exists( 'key_null', $array ) );
Output : bool(false) bool(true).
--------
[2013-05-16 10:49:05] ni...@php.net
For "normal" arrays (with no odd null-value usages), you can just use isset for
this. E.g. isset($_GET['foo'], $_GET['bar'], $_GET['baz']).
I think accepting an array for array_key_exists is not very clear, because it
could mean either "one of the keys exists" or "all of the keys exist".
Marking as Wfx, unless some clearer examples for use cases come up ;)
[2013-05-16 07:44:48] bensor987 at neuf dot fr
Description:
Why can't we give an array as the first parameter of array_key_exists() ? I
have a few cases where it would be useful. Especially when checking $_POST,
$_GET or $_REQUEST arrays (for instance).
Test script:
---
$array_to_test = array( 'key1' => 1, 'key2' => 1, 'key3' => 1 );
$array_keys = array( 'key1', 'key2', 'key3');
var_dump( array_key_exists( $array_keys, $array_to_test ) );
var_dump( (array_key_exists( 'key1', $array_to_test ) && array_key_exists(
'key2', $array_to_test ) && array_key_exists( 'key3', $array_to_test )) );//
The same as above, but much longer.
Expected result:
bool(true) bool(true)
Actual result:
--
bool(false) bool(true)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64854&edit=1
[PHP-BUG] Bug #64893 [NEW]: Crash due to dtor call happening after dtor shutdown
From: nikic Operating system: PHP version: 5.5.0RC1 Package: Scripting Engine problem Bug Type: Bug Bug description:Crash due to dtor call happening after dtor shutdown Description: If an object is created *after* the destructor shutdown, its dtor will be called when it is freed, which potentially happens during a phase of the shutdown process where the executor is no longer in a consistent state. The test script uses the ob callback (called after dtor shutdown) to create an object and bind it to to the error callback, which is later freed during zend_deactivate, as part of the executor shutdown. Result: /home/nikic/dev/php-dev/Zend/zend_hash.c(946) : ht=0x42dea5c is already destroyed Test script: --- https://bugs.php.net/bug.php?id=64893&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64893&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64893&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64893&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64893&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64893&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64893&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64893&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64893&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64893&r=support Expected behavior: https://bugs.php.net/fix.php?id=64893&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64893&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64893&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64893&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64893&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64893&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64893&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64893&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64893&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64893&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64893&r=mysqlcfg
Bug #64955 [Com]: "array to string conversion" notice should contain more information
Edit report at https://bugs.php.net/bug.php?id=64955&edit=1
ID: 64955
Comment by: ni...@php.net
Reported by:matteosistisette at gmail dot com
Summary:"array to string conversion" notice should contain
more information
Status: Not a bug
Type: Bug
Package:*General Issues
PHP Version:5.4.15
Block user comment: N
Private report: N
New Comment:
This is not just difficult, this is to the most part impossible. In this
particular case where the array->string conversion happens to be the result of
a concatenation of variables, sure, one could in theory (with a sufficient
amount of special casing) give you a variable name.
But usually this is not the case. Instead the error happens as part of some
other operation or using the result of some other operation. This particular
notice for example often occurs inside functions like array_diff. There is no
responsible "variable name" in such cases.
Previous Comments:
[2013-06-02 11:49:58] matteosistisette at gmail dot com
Ok. The correct status would be "won't fix", however.
This is a more general issue, actually. It applies to most error messages. Line
number is often not enough, and having to split a line of code into multiple
lines every time you have to debug an error (and then, get them back to one
line
so the code doesn't become unreadable) is definitely not viable.
[2013-06-02 01:01:45] ras...@php.net
That's actually surprisingly difficult to do given how bison (the parser
generator) works. You can do it quite easily in userspace though. Just break up
the line you are having trouble with over multiple lines and the line number
will
tell you which variable it is.
[2013-06-01 15:23:05] matteosistisette at gmail dot com
Description:
The "Array to string conversion" notice message should at the very least
include
the name of the array variable that is being converted to string.
A line of code may contain a lot of variables, so figuring out which one is the
unexpected array can be a pain in the ass.
Even the backtrace won't contain enough information since it only gives the
line
but not the position within the line.
Test script:
---
$string1="foo";
$string2="bar";
$string3=array("Whoops, this is an array");
$string4="bla bla";
echo $string1.$string2.$string3.$string4.
Expected result:
PHP NOTICE at /path/to/file.php (6): Array to string conversion for variable
'string3'
Actual result:
--
PHP NOTICE at /path/to/file.php (6): Array to string conversion
--
Edit this bug report at https://bugs.php.net/bug.php?id=64955&edit=1
Bug #64987 [Com]: unexpected result for call_user_func() in the debug_backtrace()
Edit report at https://bugs.php.net/bug.php?id=64987&edit=1
ID: 64987
Comment by: ni...@php.net
Reported by:tyr...@php.net
Summary:unexpected result for call_user_func() in the
debug_backtrace()
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: irrelevant
PHP Version:5.3.26
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
> When discussing this with Nikita on irc he said that we shouldn't have
> two entry in the result in the first place for call_user_func, but I think
> that removing one entry would have bigger impact on userland (there is a
> chance that some people already remove the entry manually and this change
> would make it remove o valid entry) compared to the change to fill out the
> information that was ommited before.
Misunderstanding ^^ I think having two entries is right (after all, both
functions *are* called, so they should both be in the trace). But I don't think
that the foo() call should copy the file&line info from the call_user_func()
call. It's a) redundant and b) inadequate, as the foo() call does *not* happen
in that line, but rather somewhere in the internals of call_user_func.
Now, for call_user_func in particular that distinction might be a bit fuzzy, as
call_user_func($foo) is roughly equivalent to $foo(), but what you say here
applies to all cases where a userland function is invoked from internal code.
If you just copied the file&line from the previous frame in those cases, then
they would point to some line that most likely does not even contain a
reference to the function (it just happens to be called from there, but can be
registered somewhere else).
Anyway, I don't really care much if it behaves one way or the other, but I do
think that the current behavior is the right one.
Previous Comments:
[2013-06-07 11:25:56] tyr...@php.net
it seems that the xdebug debug backtrace works the same way as it was proposed
here:
Call Stack:
0.0016 639496 1. {main}() test.php:0
0.0026 639624 2. call_user_func() test.php:9
0.0026 639624 3. foo() test.php:9
0.0026 639624 4. bar() test.php:3
0.0026 639800 5. trigger_error() test.php:7
notice that it lists both the call_user_func() and the foo() call, both of the
pointing to the same file:line
[2013-06-07 10:52:28] tyr...@php.net
sorry, I've just realized that we had a bug report about this(#44428) closed by
Dmitry with not a bug.
I still think that it would worth a second look, we either say that this is an
internal call and then it shouldn't be in the debug_backtrace output or we say
that this is useful information to the userland and have it in the backtrace,
but
then we can't have the internal function excuse.
[2013-06-07 10:48:14] tyr...@php.net
Description:
call_user_func() generates two entry to the backtrace: one for the call of the
call_user_func with the callable arg and one for the call of the callable.
the problem is that the entry only has function and args entry, but no file or
line.
This happens because the execution reaches the break here:
http://lxr.php.net/xref/PHP_5_3/Zend/zend_builtin_functions.c#2161
Which based on the comment above is there to prevent touching the stack when we
are inside the error handler, which isn't the case here.
When discussing this with Nikita on irc he said that we shouldn't have two
entry
in the result in the first place for call_user_func, but I think that removing
one entry would have bigger impact on userland (there is a chance that some
people already remove the entry manually and this change would make it remove o
valid entry) compared to the change to fill out the information that was
ommited
before.
btw it seems that the suggested behavior was present between 5.0.0 and 5.0.5:
http://3v4l.org/jI9VI#v430
5.0.5 had two debug_backtrace related fix mentioned in the changelog(#30828 and
#28377) but from a quick glance on the description it seems to be irrelevant
from this behavior change.
In case if we decide to not change the current behavior, please turn this
report
into a documentation problem as it would be nice if the docs would reflect what
information will present (or missing) in which case.
Currently we only hint that the type and args can be missing in some case.
ps: the issue is still present in master and commenting out the if with that
break produces the expected result but ofc. that isn't the proper fix.
Test script:
---
array(4) {
["file"]=>
stri
[PHP-BUG] Bug #65050 [NEW]: zend_hash_apply not interruption safe
From: nikic
Operating system:
PHP version: 5.5.0RC3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:zend_hash_apply not interruption safe
Description:
The zend_hash_apply is used all over the place, but it isn't interruption
safe (just like iteration using HashPosition).
Here is an example making use of OB callbacks in var_dump:
3: 4: &array(2) {
5: [0]=>
6: Segmentation fault (core dumped)
Valgrind output (only first entry):
==11997== Invalid read of size 4
==11997==at 0x819057F: php_var_dump (var.c:99)
==11997==by 0x81903EF: php_array_element_dump (var.c:51)
==11997==by 0x827C917: zend_hash_apply_with_arguments
(zend_hash.c:748)
==11997==by 0x8190A58: php_var_dump (var.c:146)
==11997==by 0x81903EF: php_array_element_dump (var.c:51)
==11997==by 0x827C917: zend_hash_apply_with_arguments
(zend_hash.c:748)
==11997==by 0x8190A58: php_var_dump (var.c:146)
==11997==by 0x8190C07: zif_var_dump (var.c:183)
==11997==by 0x82A72BA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:547)
==11997==by 0x82ABD3F: ZEND_DO_FCALL_SPEC_CONST_HANDLER
(zend_vm_execute.h:2328)
==11997==by 0x82A67F6: execute_ex (zend_vm_execute.h:356)
==11997==by 0x82A68AB: zend_execute (zend_vm_execute.h:381)
==11997== Address 0x447f15c is 12 bytes inside a block of size 36 free'd
==11997==at 0x402B06C: free (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==11997==by 0x823257E: _efree (zend_alloc.c:2437)
==11997==by 0x827C09B: zend_hash_del_key_or_index (zend_hash.c:512)
==11997==by 0x82FC731: ZEND_UNSET_DIM_SPEC_CV_CONST_HANDLER
(zend_vm_execute.h:33119)
==11997==by 0x82A67F6: execute_ex (zend_vm_execute.h:356)
==11997==by 0x82A68AB: zend_execute (zend_vm_execute.h:381)
==11997==by 0x8258E71: zend_call_function (zend_execute_API.c:939)
==11997==by 0x8277CD4: zend_fcall_info_call (zend_API.c:3381)
==11997==by 0x81E7B47: php_output_handler_op (output.c:962)
==11997==by 0x81E8026: php_output_op (output.c:1063)
==11997==by 0x81E5E6C: php_output_write (output.c:255)
==11997==by 0x81C9442: php_printf (main.c:682)
--
Edit bug report at https://bugs.php.net/bug.php?id=65050&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65050&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65050&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65050&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65050&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65050&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65050&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65050&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65050&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65050&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65050&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65050&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65050&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65050&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65050&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65050&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65050&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65050&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65050&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65050&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65050&r=mysqlcfg
[PHP-BUG] Bug #65051 [NEW]: count() off by one inside unset()
From: nikic
Operating system:
PHP version: 5.5.0RC3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:count() off by one inside unset()
Description:
If code is run inside an array offset unset the reported size of that array
will be off by one:
array[0]));
var_dump($this->array[0]);
}
}
$array = [[new Foo]];
$array[0][0]->array =& $array;
unset($array[0][0]);
Outputs:
int(1)
array(1) {
}
The reason is that zend_hash_del_key_or_index decrements the element count
*after* calling the bucket dtor.
--
Edit bug report at https://bugs.php.net/bug.php?id=65051&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65051&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65051&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65051&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65051&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65051&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65051&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65051&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65051&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65051&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65051&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65051&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65051&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65051&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65051&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65051&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65051&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65051&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65051&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65051&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65051&r=mysqlcfg
Req #65082 [Com]: json_encode's option for replacing ill-formd byte sequences with substitute cha
Edit report at https://bugs.php.net/bug.php?id=65082&edit=1
ID: 65082
Comment by: ni...@php.net
Reported by:masakielastic at gmail dot com
Summary:json_encode's option for replacing ill-formd byte
sequences with substitute cha
Status: Open
Type: Feature/Change Request
Package:JSON related
Operating System: All
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
It's currently possible to get a partial output using
JSON_PARTIAL_OUTPUT_ON_ERROR. This will replace invalid UTF8 strings with NULL
though. It probably would make sense to have an alternative option that inserts
the substitution character.
Previous Comments:
[2013-06-21 05:31:34] masakielastic at gmail dot com
Description:
json_encode returns false if the string contains ill-formed byte
sequences. It is hard to find the problem since a lot of web applications don't
expect the existence of ill-formed byte sequences. The one example is Symfony's
JsonResponse class.
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpFoundat
ion/JsonResponse.php#L83
Introducing json_encode's option for replacing ill-formd byte sequences with
substitute characters (such as U+FFFD) save writing the logic.
function json_encode2($value, $options, $depth)
{
if (is_scalar($value)) {
return json_encode($value, $options, $depth);
}
$value2 = [];
foreach ($value as $key => $elm) {
$value2[str_scrub($key)] = str_scrub($elm);
}
return json_encode($value2, $options, $depth);
}
// https://bugs.php.net/bug.php?id=65081
function str_scrub($str, $encoding = 'UTF-8')
{
return htmlspecialchars_decode(htmlspecialchars($str, ENT_SUBSTITUTE,
$encoding));
}
The precedent example is htmlspecialchars's ENT_SUBSTITUTE option which was
introduced
in PHP 5.4. json_encode shares the part of logic used such as
php_next_utf8_char
by htmlspecialchars since PHP 5.5.
https://github.com/php/php-src/blob/master/ext/json/json.c#L369
Another reason for introducing the option is existence of JsonSerializable
interface.
Accessing jsonSerialize method's values come from private properties is hard
or impossbile.
The one of names of candiates for the option is JSON_SUBSTITUTE similar to
htmlspecialchar's ENT_SUBSTITUTE option.
json_encode($object, JSON_SUBSTITUTE);
--
Edit this bug report at https://bugs.php.net/bug.php?id=65082&edit=1
Bug #65135 [Com]: Support for non-scalar keys in foreach() does not work with SplObjectStorage
Edit report at https://bugs.php.net/bug.php?id=65135&edit=1
ID: 65135
Comment by: ni...@php.net
Reported by:sebast...@php.net
Summary:Support for non-scalar keys in foreach() does not
work with SplObjectStorage
Status: Assigned
Type: Bug
Package:SPL related
Operating System: Irrelevant
PHP Version:5.5.0
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
The RFC only adds the ability to have non-scalar keys. It does not change the
behavior of any of our existing iterators.
I don't think we can change the SplObjectStorage behavior as it would
constitute a BC break (all current loops would break.)
Previous Comments:
[2013-06-26 16:09:58] sebast...@php.net
Description:
Quoting from https://wiki.php.net/rfc/foreach-non-scalar-keys
// NOT possible
foreach ($objectStore as $key => $value) {
// ...
}
// Instead you have to use
foreach ($objectStore as $key) {
$value = $objectStore[$key];
// ...
}
This suggests that it would work after the proposed changes. However, in PHP
5.5 (for which the RFC was accepted) this still does not work.
Test script:
---
attach(new DateTime, new StdClass);
foreach ($o as $key => $value) {
var_dump($key);
var_dump($value);
}
Expected result:
class DateTime#2 (3) {
public $date =>
string(19) "2013-06-26 18:04:30"
public $timezone_type =>
int(3)
public $timezone =>
string(13) "Europe/Berlin"
}
class stdClass#3 (0) {
}
Actual result:
--
int(0)
class DateTime#2 (3) {
public $date =>
string(19) "2013-06-26 18:03:24"
public $timezone_type =>
int(3)
public $timezone =>
string(13) "Europe/Berlin"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=65135&edit=1
Bug #65166 [Com]: PHP Generator yield causing zend_mm_heap corrupted
Edit report at https://bugs.php.net/bug.php?id=65166&edit=1
ID: 65166
Comment by: ni...@php.net
Reported by:gavroche dot bull at gmail dot com
Summary:PHP Generator yield causing zend_mm_heap corrupted
Status: Open
Type: Bug
Package:Unknown/Other Function
PHP Version:master-Git-2013-06-29 (Git)
Block user comment: N
Private report: N
New Comment:
Is it possible to reproduce this crash without the use of mongo db?
If not, it would be nice to have a backtrace for this (as described on
https://bugs.php.net/bugs-generating-backtrace.php).
Previous Comments:
[2013-06-29 21:59:27] gavroche dot bull at gmail dot com
Description:
The yield function in the example below gives a "zend_mm_heap corrupted" error.
Test script:
---
function dump($chunk = 500)
{
$m = new MongoClient();
$db = $m->dbname;
$collection = $db->selectCollection('collectionname');
$cursor = $collection->find();
$count = 0;
$output = [];
foreach ($cursor as $doc) {
$doc = array_filter($doc, function($v) { return !is_object($v); });
$output[] = $doc;
$count++;
if ($count === $chunk) {
yield json_encode($output);
$output = [];
$count = 0;
}
}
yield json_encode($output);
}
foreach(dump() as $dump) {
var_dump($dump);
}
Expected result:
No error.
Actual result:
--
zend_mm_heap corrupted
--
Edit this bug report at https://bugs.php.net/bug.php?id=65166&edit=1
Req #65283 [Com]: preg_quote escapes unnecessary characters + Doc
Edit report at https://bugs.php.net/bug.php?id=65283&edit=1
ID: 65283
Comment by: ni...@php.net
Reported by:david at grudl dot com
Summary:preg_quote escapes unnecessary characters + Doc
Status: Not a bug
Type: Feature/Change Request
Package:PCRE related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
= is used in (?=, ! is used in (?!, < is used in (?<=, > is used in (?>, : is
used in (?:. < and > are also used in (?<...>, \g<...>, etc.
Of course all these might be effectively covered by other escapes (for ? and
\), but presumably the idea here is "better safe than sorry" :) There is no
harm in escaping more characters than strictly necessary, but quite a lot of
harm in missing some edge-case ;)
Previous Comments:
[2013-07-19 22:37:23] david at grudl dot com
Abc, please double-read my issue ;)
So once more:
1) preg_quote is quoting characters (these = ! < > : ) which may not be
quoted. Could you show me scenario, when these (again, THESE) characters should
be escaped?
2) in documentation is missing information that preg_quote quotes \x00
[2013-07-18 05:33:25] a...@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
from the doc
"preg_quote — Quote regular expression characters"
so that's exactly what you blame ;)
the scenario is pretty simple
$pattern = '[/';
preg_match('/' . preg_quote($pattern) . '/', $subj);
[2013-07-18 00:27:52] david at grudl dot com
Description:
preg_quote() escapes all PCRE metacharacters. It also escapes these characters
= ! < > : which have no special meaning. I am unable to find out any scenario
when these characters should be escaped, do you? For assertions it is enough to
escape ?. So they shouldn't be escaped.
There is also problem in documentation, preg_quote escapes \x00, but it is not
mentioned.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65283&edit=1
Bug #65305 [Com]: $this keyword is treated like a variable under certain circumstances
Edit report at https://bugs.php.net/bug.php?id=65305&edit=1
ID: 65305
Comment by: ni...@php.net
Reported by:ryan at skidmore dot pro
Summary:$this keyword is treated like a variable under
certain circumstances
Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: Linux/Ubuntu
PHP Version:5.4.17
Block user comment: N
Private report: N
New Comment:
Why would it be logical? PHP treats all variables case-sensitively, so it's not
really obvious to me why $this should be any different in this regard.
Previous Comments:
[2013-07-21 15:03:08] ryan at skidmore dot pro
Surely it would be logical to treat $This exactly the same as $this though?
[2013-07-21 14:54:36] ni...@php.net
$this *is* a variable and variables in PHP are case-sensitive. Thus your code
makes a method call on null, which results in a fatal error.
[2013-07-21 14:47:47] ryan at skidmore dot pro
Description:
When capitalising the first letter of the $this keyword to $This and then
assigning it to a variable (with appropiate class structures) like this:
"$Variable = $This->Class1->Function1();" causes PHP to throw an error and not
display the page, when $This is changed to $this, it works fine.
Test script:
---
This test script is fit into two parts, for two separate files.
** UNCOMMENT THE LINES TO REPRODUCE PROBLEM
** FILE 1 ** (The file to be run)
Class Class1
{
Public $Class2Inst;
Public function __construct()
{
include("phpbug2.php"); // *** Change this to the path of
the other file.
$this->Class2Inst = new Class2;
//$Variable1 = $This->Class2Inst->Func1(); // This produces
error
//$Variable2 = $this->Class2Inst->Func1(); // This does not
produce error
echo $Variable2;
}
}
$Class1Inst = new Class1;
** FILE 2 ** The file that gets included
Class Class2
{
Public function Func1()
{
return "Function 1 is being run";
}
}
Expected result:
The expected result is that Func1 within the Class2 class is run.
Actual result:
--
The $This keyword is treated like a variable, instead of like a keyword.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65305&edit=1
Req #65257 [Com]: new function for preventing XSS attack
Edit report at https://bugs.php.net/bug.php?id=65257&edit=1
ID: 65257
Comment by: ni...@php.net
Reported by:masakielastic at gmail dot com
Summary:new function for preventing XSS attack
Status: Open
Type: Feature/Change Request
Package:JSON related
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
I don't really understand this issue (and also why the JSON_HEX_* flags were
necessary in the first place). If you are going to embed JSON into HTML, why
not use the usual htmlspecialchars function? Why do we have to implement HTML
escaping functionality inside json_encode? Both things seem very distinct to me.
Previous Comments:
[2013-07-26 22:31:00] yohg...@php.net
Alternatively, we may introduce JSON_UNICODE and make it default. Unicode
escape
is defined in FRC4627. e.g. \uD834\uDD1E
This would be most secure way of escaping unicode. The disadvantage is
increased
data size.
[2013-07-26 21:23:07] yohg...@php.net
Sounds good to me. Anyone else have comments?
[2013-07-13 14:31:24] masakielastic at gmail dot com
Description:
Although JSON_HEX_TAG, JSON_HEX_APOS, JSON_HEX_QUOT, JSON_HEX_AMP options
were added in PHP 5.3 for preventing XSS attack,
a lot of people don't specify these options.
https://github.com/search?l=PHP&q=json_encode&ref=advsearch&type=Code
The one of PHP's goal is to provide a secure way for creating
web application without CMSes and frameworks.
The one of mesures for the problem is providing new function
with make these options default.
Adding recommend opitons as a default also make sense.
function json_secure_encode($value, $options = 0, $depth = 512)
{
// JSON_NOTUTF8_SUBSTITUTE
// an option replacing ill-formd byte sequences with substitute characters
// https://bugs.php.net/bug.php?id=65082
$options |= JSON_HEX_TAG
| JSON_HEX_APOS | JSON_HEX_QUOT
| JSON_HEX_AMP | JSON_NOTUTF8_SUBSTITUTE;
return json_secure_encode($value, $options, $depth);
}
A shortcut for these options may be helpful a bit.
if (!defined('JSON_QUOTES')) {
define('JSON_QUOTES', JSON_HEX_TAG | JSON_HEX_APOS | JSON_HEX_AMP |
JSON_HEX_QUOT);
}
The following RFC shows various functions for less options.
Escaping RFC for PHP Core
https://wiki.php.net/rfc/escaper
Ruby on Rails provide json_escape via ERB::Util.
http://api.rubyonrails.org/classes/ERB/Util.html
OWAPS shows the guidelines for XSS attack.
RULE #3.1 - HTML escape JSON values in an HTML context and read the data with
JSON.parse
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Shee
t#RULE_.233.1_-
_HTML_escape_JSON_values_in_an_HTML_context_and_read_the_data_with_JSON.parse
As a sidenote, the default HTTP headers of Rails
include "X-Content-Type-Options: nosniff" for IE.
http://edgeguides.rubyonrails.org/security.html#default-headers
https://github.com/rails/docrails/blob/master/actionpack/lib/action_dispatch/rai
ltie.rb#L20=L24
The following articles describe JSON-based XSS exploitation.
http://blog.watchfire.com/wfblog/2011/10/json-based-xss-exploitation.html
https://superevr.com/blog/2012/exploiting-xss-in-ajax-web-applications
--
Edit this bug report at https://bugs.php.net/bug.php?id=65257&edit=1
[PHP-BUG] Bug #65382 [NEW]: Segfault in closure_030.phpt
From: nikic Operating system: PHP version: 5.5.2RC1 Package: Scripting Engine problem Bug Type: Bug Bug description:Segfault in closure_030.phpt Description: closure_030.phpt segfaults on Travis. Short repro script: __invoke(); Valgrind output: ~/dev/php-dev$ USE_ZEND_ALLOC=0 valgrind sapi/cli/php t22.php ==2074== Memcheck, a memory error detector ==2074== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==2074== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==2074== Command: sapi/cli/php t22.php ==2074== ==2074== Invalid read of size 1 ==2074==at 0x8260376: zval_call_destructor (zend_execute_API.c:203) ==2074==by 0x8286B2D: zend_hash_reverse_apply (zend_hash.c:775) ==2074==by 0x8260452: shutdown_destructors (zend_execute_API.c:217) ==2074==by 0x8274BC3: zend_call_destructors (zend.c:923) ==2074==by 0x81D6742: php_request_shutdown (main.c:1745) ==2074==by 0x831EDD9: do_cli (php_cli.c:1177) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== Address 0x44828f4 is 12 bytes inside a block of size 20 free'd ==2074==at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2074==by 0x823C602: _efree (zend_alloc.c:2437) ==2074==by 0x82AB651: i_zval_ptr_dtor (zend_execute.h:82) ==2074==by 0x82B1AC3: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:630) ==2074==by 0x82B1CD3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:682) ==2074==by 0x82B097E: execute_ex (zend_vm_execute.h:356) ==2074==by 0x82B0A33: zend_execute (zend_vm_execute.h:381) ==2074==by 0x827636C: zend_execute_scripts (zend.c:1316) ==2074==by 0x81D85C6: php_execute_script (main.c:2484) ==2074==by 0x831E192: do_cli (php_cli.c:994) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== ==2074== Invalid read of size 4 ==2074==at 0x825F4F3: zval_refcount_p (zend.h:397) ==2074==by 0x826038A: zval_call_destructor (zend_execute_API.c:203) ==2074==by 0x8286B2D: zend_hash_reverse_apply (zend_hash.c:775) ==2074==by 0x8260452: shutdown_destructors (zend_execute_API.c:217) ==2074==by 0x8274BC3: zend_call_destructors (zend.c:923) ==2074==by 0x81D6742: php_request_shutdown (main.c:1745) ==2074==by 0x831EDD9: do_cli (php_cli.c:1177) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== Address 0x44828f0 is 8 bytes inside a block of size 20 free'd ==2074==at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2074==by 0x823C602: _efree (zend_alloc.c:2437) ==2074==by 0x82AB651: i_zval_ptr_dtor (zend_execute.h:82) ==2074==by 0x82B1AC3: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:630) ==2074==by 0x82B1CD3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:682) ==2074==by 0x82B097E: execute_ex (zend_vm_execute.h:356) ==2074==by 0x82B0A33: zend_execute (zend_vm_execute.h:381) ==2074==by 0x827636C: zend_execute_scripts (zend.c:1316) ==2074==by 0x81D85C6: php_execute_script (main.c:2484) ==2074==by 0x831E192: do_cli (php_cli.c:994) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== ... and so on -- Edit bug report at https://bugs.php.net/bug.php?id=65382&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65382&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65382&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65382&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65382&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65382&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65382&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65382&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65382&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65382&r=support Expected behavior: https://bugs.php.net/fix.php?id=65382&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65382&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65382&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65382&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65382&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65382&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65382&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65382&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65382&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65382&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65382&r=mysqlcfg
[PHP-BUG] Bug #65384 [NEW]: pg_last_notice test failures
From: nikic Operating system: PHP version: 5.5.2RC1 Package: PostgreSQL related Bug Type: Bug Bug description:pg_last_notice test failures Description: The following pg_last_notice related tests currently fail on Travis CI: PostgreSQL notice function [ext/pgsql/tests/09notice.phpt] Bug #32223 (weird behaviour of pg_last_notice) [ext/pgsql/tests/80_bug32223.phpt] Bug #32223 (weird behaviour of pg_last_notice using define) [ext/pgsql/tests/80_bug32223b.phpt] The diffs are: 09notice.phpt: 001+ Cannot find notice message in hash 002+ bool(false) 003+ 001- Notice: pg_query(): %s already a transaction in progress in %s on line %d 002- %s already a transaction in progress 80_bug32223.phpt: 005+ bool(false) 005- string(14) "NOTICE: 1" 80_bug32223b.phpt: 005+ bool(false) 005- string(14) "NOTICE: 1" -- Edit bug report at https://bugs.php.net/bug.php?id=65384&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65384&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65384&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65384&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65384&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65384&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65384&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65384&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65384&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65384&r=support Expected behavior: https://bugs.php.net/fix.php?id=65384&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65384&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65384&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65384&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65384&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65384&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65384&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65384&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65384&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65384&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65384&r=mysqlcfg
Bug #64979 [Com]: Wrong behavior of static variables in closure generators
Edit report at https://bugs.php.net/bug.php?id=64979&edit=1 ID: 64979 Comment by: ni...@php.net Reported by:jan at fb dot com Summary:Wrong behavior of static variables in closure generators Status: Assigned Type: Bug Package:*Programming Data Structures Operating System: Linux PHP Version:5.5.0RC2 Assigned To:nikic Block user comment: N Private report: N New Comment: Probably related to the copy of the closure that is made in http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_generators.c#241, which simply uses function_add_ref (http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_compile.c#2983), whereas the closures own code does the copy in a different way: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_closures.c#459 Previous Comments: [2013-06-06 05:54:31] jan at fb dot com Description: Each closure instance should have its own set of static variables. This works perfectly with non-generator closures (replace yield by return array in the test script), but not with generator closures (run the test script), where static variables seem to behave like a normal local variables. Test script: --- https://bugs.php.net/bug.php?id=64979&edit=1
Bug #61774 [Com]: Public object variables with numbers as name are not public after unserialize
Edit report at https://bugs.php.net/bug.php?id=61774&edit=1 ID: 61774 Comment by: ni...@php.net Reported by:pandenitz at mail dot ru Summary:Public object variables with numbers as name are not public after unserialize Status: Open Type: Bug Package:Class/Object related Operating System: Win 7 64x PHP Version:5.3.11RC2 Block user comment: N Private report: N New Comment: Can repro on PHP 5.3, but not on 5.4. Everything fine there. Previous Comments: [2012-04-19 14:43:30] pandenitz at mail dot ru Description: Object variables with numbers as name are not public after unserialize. So i.e. get_object_vars() doesn't return this vars because they are not public Test script: --- $varname = 1; $a->test = 1; var_dump($a); print_r($a); echo ''; $s = serialize($a); $a2 = unserialize($s); var_dump($a2); print_r($a2); echo ''; var_dump(get_object_vars($a2)); print_r(get_object_vars($a2)); Expected result: Such vars should be public after unserialize. Actual result: -- Vars are not actually public. -- Edit this bug report at https://bugs.php.net/bug.php?id=61774&edit=1
Bug #61767 [Com]: Shutdown functions not called in certain error situation
Edit report at https://bugs.php.net/bug.php?id=61767&edit=1
ID: 61767
Comment by: ni...@php.net
Reported by:shiranai7 at hotmail dot com
Summary:Shutdown functions not called in certain error
situation
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Win7
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
This seems related: https://bugs.php.net/bug.php?id=60909
Previous Comments:
[2012-04-19 09:07:06] shiranai7 at hotmail dot com
Allow me to re-specify the expected result:
--
Error handler called
Fatal error: Uncaught exception 'ErrorException' with message 'Undefined
variable: undefined' in C:\Dokumenty\localhost\base\test_case1.php:14 Stack
trace: #0 _example_(14): {closure}(8, 'Undefined varia...',
'C:\Dokumenty\lo...', 14, Array) #1 {main} thrown in
C:\Dokumenty\localhost\base\test_case1.php on line 14
Shutting down Array ( [type] => 1 [message] => Uncaught exception
'ErrorException' with message 'Undefined variable: undefined' in _example_:14
Stack trace: ... [file] => _example_ [line] => 14 )
--
This is because the error_handler gets actually called for the E_NOTICE - so an
exception should be thrown (and later uncaught in the example). But the
exception gets *eaten* as I described.
[2012-04-18 18:39:02] shiranai7 at hotmail dot com
Description:
I am using register_shutdown_function() toghether with error_get_last() and
set_error_handler() to "handle" fatal errors (to display message in debug
screen etc, details do not matter).
Everything works perfectly except for one specific scenario - If there is an
error caused by calling a method on UNDEFINED (really undefined, not null etc)
variable, then the following happens (NOT OK, UNEXPECTED):
1. registered error_handler is invoked for E_NOTICE (undefined variable)
2. the error_handler throws an ErrorException
3. the exception gets *eaten* by something, it never makes it out of the
error_handler
4. PHP exits with FATAL error (Call to a member function foo() on a non-object)
5. No shutdown functions get called
If the variable is not UNDEFINED but just not an object (e.g. null), everything
happens as follows (ALL OK, EXPECTED):
1. PHP exits with FATAL error (Call to a member function foo() on a non-object)
2. Registered shutdown functions are called
If I return TRUE from the error_handler, following happens (OK, BUT NOT
ACCEPTABLE):
1. registered error_handler is invoked for E_NOTICE (undefined variable)
2. the error_handler returns TRUE
3. PHP exits with FATAL error (Call to a member function foo() on a non-object)
4. Registered shutdown functions are called
Test script:
---
set_error_handler(function($code, $msg, $file = null, $line = null) {
echo "Error handler called\n";
throw new \ErrorException($msg, $code, 0, $file, $line);
});
register_shutdown_function(function(){
echo "Shutting down\n";
print_r(error_get_last());
});
// $undefined = null; // defined variable does not cause problems
$undefined->foo();
Expected result:
Fatal error: Call to a member function foo() on a non-object in _example_ on
line 14
Shutting down Array ( [type] => 1 [message] => Call to a member function foo()
on a non-object [file] => _example_ [line] => 14 )
Actual result:
--
Error handler called
Fatal error: Call to a member function foo() on a non-object in _example_ on
line 13
--
Edit this bug report at https://bugs.php.net/bug.php?id=61767&edit=1
Bug #60909 [Com]: custom error handler throwing Exception + fatal error = no shutdown function
Edit report at https://bugs.php.net/bug.php?id=60909&edit=1 ID: 60909 Comment by: ni...@php.net Reported by:tyr...@php.net Summary:custom error handler throwing Exception + fatal error = no shutdown function Status: Open Type: Bug Package:Scripting Engine problem Operating System: linux PHP Version:5.4.0RC6 Block user comment: N Private report: N New Comment: Together with https://bugs.php.net/bug.php?id=61767 it is a bit more clear under which circumstances this occurs: 1. A non-fatal error is thrown 2. The error handler throws an Exception 3. A fatal error is thrown In this particular case: 1. require() throws an E_WARNING (Warning: require(notfound.php): failed to open stream: No such file or directory). 2. The error handler throws the Exception 3. require() throws an E_COMPILE_ERROR (Fatal error: require(): Failed opening required 'notfound.php') Previous Comments: [2012-02-09 14:33:57] jpa...@php.net Ok I can reproduce. Try replacing your require (which generates E_COMPILE_ERROR) by an unknown function call (which generates E_ERROR), and all's just fine So there is a trick in the error engine, any kind of fatal shouldn't be handled by user defined error handlers, here we got proof it's not the case Tip: Reproduced on 5.3.10 as well [2012-01-27 18:07:20] tyr...@php.net Description: first of all sorry for the weird Summary, I couldn't come up with a better one. it is weird. so it seems that if you have a shutdown function callback set and a custom error handler which would throw and exception and you happen to have a fatal error, the shutdown function won't be called. See the attached script, the error handler shouldn't really do anything here, because it won't be called for the fatals, but somehow it still screw things up. If I remove the error handler, I will see the "!!!shutdown!!!" printed. If I put a "return false;" before the throw I will see the "!!!shutdown!!!" printed. If I add E_NOTICE as the $error_type to the set_error_handler call I will see the "!!!shutdown!!!" printed. If I add E_WARNING as the $error_type to the set_error_handler call I will NOT see the "!!!shutdown!!!" printed. wtf? Test script: --- https://bugs.php.net/bug.php?id=60909&edit=1
Bug #60909 [Com]: custom error handler throwing Exception + fatal error = no shutdown function
Edit report at https://bugs.php.net/bug.php?id=60909&edit=1 ID: 60909 Comment by: ni...@php.net Reported by:tyr...@php.net Summary:custom error handler throwing Exception + fatal error = no shutdown function Status: Open Type: Bug Package:Scripting Engine problem Operating System: linux PHP Version:5.4.0RC6 Block user comment: N Private report: N New Comment: So, this is what I think is happening here: 1. The first non-fatal error (here warning) throws an Exception, i.e. sets EG(exception) 2. The second fatal error then causes a zend_bailout() moving us directly to php_request_shutdown() 3. During the shutdown sequence PHP will try to call the shutdown handler using call_user_function(). 4. As EG(exception) is still set, the call is not allows (see http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_execute_API.c#775). Previous Comments: [2012-04-19 23:06:26] ni...@php.net Together with https://bugs.php.net/bug.php?id=61767 it is a bit more clear under which circumstances this occurs: 1. A non-fatal error is thrown 2. The error handler throws an Exception 3. A fatal error is thrown In this particular case: 1. require() throws an E_WARNING (Warning: require(notfound.php): failed to open stream: No such file or directory). 2. The error handler throws the Exception 3. require() throws an E_COMPILE_ERROR (Fatal error: require(): Failed opening required 'notfound.php') [2012-02-09 14:33:57] jpa...@php.net Ok I can reproduce. Try replacing your require (which generates E_COMPILE_ERROR) by an unknown function call (which generates E_ERROR), and all's just fine So there is a trick in the error engine, any kind of fatal shouldn't be handled by user defined error handlers, here we got proof it's not the case Tip: Reproduced on 5.3.10 as well [2012-01-27 18:07:20] tyr...@php.net Description: first of all sorry for the weird Summary, I couldn't come up with a better one. it is weird. so it seems that if you have a shutdown function callback set and a custom error handler which would throw and exception and you happen to have a fatal error, the shutdown function won't be called. See the attached script, the error handler shouldn't really do anything here, because it won't be called for the fatals, but somehow it still screw things up. If I remove the error handler, I will see the "!!!shutdown!!!" printed. If I put a "return false;" before the throw I will see the "!!!shutdown!!!" printed. If I add E_NOTICE as the $error_type to the set_error_handler call I will see the "!!!shutdown!!!" printed. If I add E_WARNING as the $error_type to the set_error_handler call I will NOT see the "!!!shutdown!!!" printed. wtf? Test script: --- https://bugs.php.net/bug.php?id=60909&edit=1
Bug #60909 [Com]: custom error handler throwing Exception + fatal error = no shutdown function
Edit report at https://bugs.php.net/bug.php?id=60909&edit=1 ID: 60909 Comment by: ni...@php.net Reported by:tyr...@php.net Summary:custom error handler throwing Exception + fatal error = no shutdown function Status: Open Type: Bug Package:Scripting Engine problem Operating System: linux PHP Version:5.4.0RC6 Block user comment: N Private report: N New Comment: I tried adding an EG(exception) = NULL; at the start of php_request_shutdown() and it indeed fixes the issue. Though probably that's not the right way to fix this. Previous Comments: [2012-04-19 23:40:57] ni...@php.net So, this is what I think is happening here: 1. The first non-fatal error (here warning) throws an Exception, i.e. sets EG(exception) 2. The second fatal error then causes a zend_bailout() moving us directly to php_request_shutdown() 3. During the shutdown sequence PHP will try to call the shutdown handler using call_user_function(). 4. As EG(exception) is still set, the call is not allows (see http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_execute_API.c#775). [2012-04-19 23:06:26] ni...@php.net Together with https://bugs.php.net/bug.php?id=61767 it is a bit more clear under which circumstances this occurs: 1. A non-fatal error is thrown 2. The error handler throws an Exception 3. A fatal error is thrown In this particular case: 1. require() throws an E_WARNING (Warning: require(notfound.php): failed to open stream: No such file or directory). 2. The error handler throws the Exception 3. require() throws an E_COMPILE_ERROR (Fatal error: require(): Failed opening required 'notfound.php') [2012-02-09 14:33:57] jpa...@php.net Ok I can reproduce. Try replacing your require (which generates E_COMPILE_ERROR) by an unknown function call (which generates E_ERROR), and all's just fine So there is a trick in the error engine, any kind of fatal shouldn't be handled by user defined error handlers, here we got proof it's not the case Tip: Reproduced on 5.3.10 as well [2012-01-27 18:07:20] tyr...@php.net Description: first of all sorry for the weird Summary, I couldn't come up with a better one. it is weird. so it seems that if you have a shutdown function callback set and a custom error handler which would throw and exception and you happen to have a fatal error, the shutdown function won't be called. See the attached script, the error handler shouldn't really do anything here, because it won't be called for the fatals, but somehow it still screw things up. If I remove the error handler, I will see the "!!!shutdown!!!" printed. If I put a "return false;" before the throw I will see the "!!!shutdown!!!" printed. If I add E_NOTICE as the $error_type to the set_error_handler call I will see the "!!!shutdown!!!" printed. If I add E_WARNING as the $error_type to the set_error_handler call I will NOT see the "!!!shutdown!!!" printed. wtf? Test script: --- https://bugs.php.net/bug.php?id=60909&edit=1
Bug #61778 [Com]: Crash when overloaded method called from class constructor
Edit report at https://bugs.php.net/bug.php?id=61778&edit=1
ID: 61778
Comment by: ni...@php.net
Reported by:james dot thomsen at gmail dot com
Summary:Crash when overloaded method called from class
constructor
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Windows 2003
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
This script runs fine on CLI for me. Could you see whether running on CLI works
for you?
Previous Comments:
[2012-04-19 20:20:31] james dot thomsen at gmail dot com
Description:
If a class overrides a method but with a different signature and that method is
called in the constructor and if error_reporting is set to display strict
errors and if the classes are defined in reverse order, PHP will crash. In my
test script, if class one is defined before class two, PHP won't crash. I
realize that overridden methods need to have identical signatures, but I would
expect a warning and not a crash.
Test script:
---
error_reporting(-1);
class two extends one{
public function __construct(){
$this->error(7);
}
private function error($n){
echo 'two';
}
}
class one{
private function error(){
echo 'one';
}
}
new two;
Expected result:
two
Actual result:
--
FastCGI Error
The FastCGI Handler was unable to process the request.
Error Details:
The FastCGI process exited unexpectedly
Error Number: -2147467259 (0x80004005).
Error Description: Unspecified error
HTTP Error 500 - Server Error.
Internet Information Services (IIS)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61778&edit=1
Req #61790 [Com]: Feature Request for create_closure() function
Edit report at https://bugs.php.net/bug.php?id=61790&edit=1 ID: 61790 Comment by: ni...@php.net Reported by:thegreatall at gmail dot com Summary:Feature Request for create_closure() function Status: Open Type: Feature/Change Request Package:*Programming Data Structures Operating System: N/A PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I'm not sure I understand your issue. create_function() is just a wrapper around eval(). The evils of eval() are also the evils of create_function(). And, as you showed, this is trivial to implement in userland. I really wouldn't like PHP to add further functions encouraging bad coding style. Previous Comments: [2012-04-20 15:55:53] thegreatall at gmail dot com Description: As I am sure many of you know of the create_function() function, but this actually creates a named function in the global scope. This can be undesirable if a user is creating an unknown number of functions because it fills memory with named execution points but once the variable looses it's references it should be cleaned up by the garbage collector. I am asking for a create_closure() function to do the same thing that create_function does, but return a closure instead of a string containing the name to a newly created named function. You can simulate a function like this using eval, but we all know the evils of eval. An example of why someone would like to do this: A developer creates a framework which handles classes to records in the database. When records get updated/created/pulled it has a "hooks" on the record level that allows custom "hooks" to be installed on the record and executed on the specific records. The code for the hook is not accessible/modifiable by the user only the developers that have database access, but each user may install that hook on a specific record. So if we had a hook that IMs users when specific records are modified in the database and 5000 users want this hook installed on that record it installs 5000 hooks on this record and creates 5000 named functions but each function would only be executed once and can/should be cleaned by the garbage collector. (I know there is a more optimal way to achieve this specific example, but if I need to change the list of arguments it has to recompile the function creating a new named function. This is not an issue with closures because they are not named functions and the garbage collector cleans them up after they are de-referenced. Test script: --- https://bugs.php.net/bug.php?id=61790&edit=1
Bug #61660 [Com]: bin2hex(hex2bin($data)) != $data
Edit report at https://bugs.php.net/bug.php?id=61660&edit=1
ID: 61660
Comment by: ni...@php.net
Reported by:krtek4+php at gmail dot com
Summary:bin2hex(hex2bin($data)) != $data
Status: Re-Opened
Type: Bug
Package:*General Issues
Operating System: Debian Linux
PHP Version:5.4.1RC1
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
@Stas: Just to be sure we are on the same page:
a) This does not break BC in any significant way. Using the function with odd
length was wrong from the start. It definitely breaks less than other changes
that landed to all branches, like the handling of invalid multibyte sequences
in json_encode.
b) If we don't change it now, it will be hard to do so later. PHP 5.4 isn't
used much yet, so people didn't have much chance to misuse this function. This
may change in the future.
c) From hour long discussions on IRC it turns out that this is largely a
documentation problem. Most people involved in the discussion thought that
hex2bin() converts hexadecimal numbers to binary numbers (which is wrong). This
has now be clarified in the docs: http://de3.php.net/hex2bin
If you wish so, I will revert the change. But I will spend no more time
discussing this. I already spent several hours in discussions about this rather
unimportant issue.
Thanks,
Nikita.
Previous Comments:
[2012-04-26 21:06:23] s...@php.net
I do not think BC break in 5.4 is a good idea.
[2012-04-11 06:13:50] theanomaly dot is at gmail dot com
The patch currently in master still leaves a remanent problem. First,
var_dump(hex2bin('')) still returns string(0) "". Whether or not this is
acceptable is arguable. Since 0x00 is null, but an empty string isn't really
null.
For example:
var_dump(unpack('H*',hex2bin(''))); // will give me string(0) ""
Whereas:
var_dump(unpack('H*',hex2bin('00'))); // will give me string(2) ""
and:
var_dump(hex2bin('00')); // will give me string(1) "" # which is what I expect
So the warning needs to be amended for an empty string as well as odd-sized hex.
Additionally, the function now returns a bool(false), breaking BC.
I suggest a second optional argument to return partial binary (potentially
broken binary) even on error in the event the user wants to maintain backwards
compatibility. I'll be happy to submit another patch for this if there are no
objections.
[2012-04-08 20:51:36] ni...@php.net
After some further discussion on IRC we agreed that it is best to throw a
warning. The reasoning is as outlined in my previous comment.
The warning is implemented with
https://github.com/php/php-src/commit/7ae93a2c4c8a51cc2aec9977ce3c83c100e382a0.
[2012-04-08 20:45:41] ni...@php.net
Automatic comment on behalf of nikic
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=7ae93a2c4c8a51cc2aec9977ce3c83c100e382a0
Log: Fix bug #61660: bin2hex(hex2bin($data)) != $data
[2012-04-08 16:23:50] theanomaly dot is at gmail dot com
We have no problem type juggling a string to an int as the first
non-whitespace,
non-zero number character...
var_dump(1 + "\t\r\n 0001"); // int(2)
Then, equally, we should have no problem interpreting a hexadecimal
representation of 1 as 01.
:)
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=61660
--
Edit this bug report at https://bugs.php.net/bug.php?id=61660&edit=1
[PHP-BUG] Bug #61964 [NEW]: finfo_open with directory causes invalid free
From: nikic Operating system: PHP version: master-Git-2012-05-06 (Git) Package: Filesystem function related Bug Type: Bug Bug description:finfo_open with directory causes invalid free Description: The simple script , str=, ptr=0xbfff996c) at malloc.c:6283 #5 0x00a30168 in munmap_chunk (p=) at malloc.c:3540 #6 0x081ffde1 in apprentice_load (ms=0xb717d8f8, magicp=0xbfffa9bc, nmagicp=0xbfffa9c0, fn=0xb717d150 "/home/nikic/dev/Phuzzy/results", action=0) at /home/nikic/dev/php-src/ext/fileinfo/libmagic/apprentice.c:814 #7 0x081fecc9 in apprentice_1 (ms=0xb717d8f8, fn=0xb717d150 "/home/nikic/dev/Phuzzy/results", action=0, mlist=0xb717d1a0) at /home/nikic/dev/php-src/ext/fileinfo/libmagic/apprentice.c:275 #8 0x081fef8c in file_apprentice (ms=0xb717d8f8, fn=0xb717d150 "/home/nikic/dev/Phuzzy/results", action=0) at /home/nikic/dev/php-src/ext/fileinfo/libmagic/apprentice.c:369 #9 0x0820975e in magic_load (ms=0xb717d8f8, magicfile=0xbfffaaec "/home/nikic/dev/Phuzzy/results") at /home/nikic/dev/php-src/ext/fileinfo/libmagic/magic.c:308 #10 0x081fdc23 in zif_finfo_open (ht=2, return_value=0xb717c2cc, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0, tsrm_ls=0x8c0f070) at /home/nikic/dev/php-src/ext/fileinfo/fileinfo.c:345 #11 0x085cf628 in zend_do_fcall_common_helper_SPEC (execute_data=0xb716007c, tsrm_ls=0x8c0f070) at /home/nikic/dev/php-src/Zend/zend_vm_execute.h:642 #12 0x085d6ddb in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xb716007c, tsrm_ls=0x8c0f070) at /home/nikic/dev/php-src/Zend/zend_vm_execute.h:2219 #13 0x085cd8d5 in execute (op_array=0xb717cc14, tsrm_ls=0x8c0f070) at /home/nikic/dev/php-src/Zend/zend_vm_execute.h:410 #14 0x0859202e in zend_execute_scripts (type=8, tsrm_ls=0x8c0f070, retval=0x0, file_count=3) at /home/nikic/dev/php-src/Zend/zend.c:1272 #15 0x084f4e91 in php_execute_script (primary_file=0xbfffe110, tsrm_ls=0x8c0f070) at /home/nikic/dev/php-src/main/main.c:2473 #16 0x086dcbc9 in do_cli (argc=2, argv=0xb3b4, tsrm_ls=0x8c0f070) at /home/nikic/dev/php-src/sapi/cli/php_cli.c:988 #17 0x086de0ed in main (argc=2, argv=0xb3b4) at /home/nikic/dev/php-src/sapi/cli/php_cli.c:1361 The invalid free occurs in https://github.com/php/php-src/blob/master/ext/fileinfo/libmagic/apprentice.c#L814. The code for loading from a directory seems completely broken: The filenames are snprintf'd into the mfn variable, which is a char[MAXPATHLEN]. For every file that variable is then written into the array, without further copying: filearr[files++] = mfn; So basically at the end filearr just contains the last scanned path multiple times. In the second loop the individual filearr elements are then freed, which is wrong in two senses: a) it's always the same array element, so it would be a multi-free b) mfn is an array, it was never allocated, so it shouldn't be freed. The fix should be to copy mfn into a separate pointer when doing filearr[files++] = mfn; :) -- Edit bug report at https://bugs.php.net/bug.php?id=61964&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61964&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61964&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61964&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61964&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61964&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61964&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61964&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61964&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61964&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61964&r=support Expected behavior: https://bugs.php.net/fix.php?id=61964&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61964&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61964&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61964&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61964&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61964&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61964&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61964&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61964&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61964&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61964&r=mysqlcfg
Bug #61660 [Com]: bin2hex(hex2bin($data)) != $data
Edit report at https://bugs.php.net/bug.php?id=61660&edit=1
ID: 61660
Comment by: ni...@php.net
Reported by:krtek4+php at gmail dot com
Summary:bin2hex(hex2bin($data)) != $data
Status: Re-Opened
Type: Bug
Package:*General Issues
Operating System: Debian Linux
PHP Version:5.4.1RC1
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
@personal_homepage_tools at hochsitze dot com:
I'm not sure I understand you. What's the issue with that comment? Do you
disagree that a padding can be added to either sides?
Previous Comments:
[2012-05-06 22:55:57] personal_homepage_tools at hochsitze dot com
This is hardly believable. This bug is so much obvious that it hurts to read
the comment "The reason is simple: A padding can be either added on the left or
on the right. E.g. "af52b" could be interpreted both as "0af52b" and as
"af52b0".". Anybody writing this must have failed in CS101 (hard!) - how is it
working that persons who write this still obviously work for this company?
I know it is hard to get something as old as PHP in a functional,
future-oriented state, but as long as comments like this from official @php.net
accounts are not deleted immediately this will not happen IMHO.
--------
[2012-04-26 21:22:12] ni...@php.net
@Stas: Just to be sure we are on the same page:
a) This does not break BC in any significant way. Using the function with odd
length was wrong from the start. It definitely breaks less than other changes
that landed to all branches, like the handling of invalid multibyte sequences
in json_encode.
b) If we don't change it now, it will be hard to do so later. PHP 5.4 isn't
used much yet, so people didn't have much chance to misuse this function. This
may change in the future.
c) From hour long discussions on IRC it turns out that this is largely a
documentation problem. Most people involved in the discussion thought that
hex2bin() converts hexadecimal numbers to binary numbers (which is wrong). This
has now be clarified in the docs: http://de3.php.net/hex2bin
If you wish so, I will revert the change. But I will spend no more time
discussing this. I already spent several hours in discussions about this rather
unimportant issue.
Thanks,
Nikita.
[2012-04-26 21:06:23] s...@php.net
I do not think BC break in 5.4 is a good idea.
[2012-04-11 06:13:50] theanomaly dot is at gmail dot com
The patch currently in master still leaves a remanent problem. First,
var_dump(hex2bin('')) still returns string(0) "". Whether or not this is
acceptable is arguable. Since 0x00 is null, but an empty string isn't really
null.
For example:
var_dump(unpack('H*',hex2bin(''))); // will give me string(0) ""
Whereas:
var_dump(unpack('H*',hex2bin('00'))); // will give me string(2) ""
and:
var_dump(hex2bin('00')); // will give me string(1) "" # which is what I expect
So the warning needs to be amended for an empty string as well as odd-sized hex.
Additionally, the function now returns a bool(false), breaking BC.
I suggest a second optional argument to return partial binary (potentially
broken binary) even on error in the event the user wants to maintain backwards
compatibility. I'll be happy to submit another patch for this if there are no
objections.
[2012-04-08 20:51:36] ni...@php.net
After some further discussion on IRC we agreed that it is best to throw a
warning. The reasoning is as outlined in my previous comment.
The warning is implemented with
https://github.com/php/php-src/commit/7ae93a2c4c8a51cc2aec9977ce3c83c100e382a0.
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=61660
--
Edit this bug report at https://bugs.php.net/bug.php?id=61660&edit=1
Bug #61945 [Com]: array returned from __get method gices a notice when trying to change a value
Edit report at https://bugs.php.net/bug.php?id=61945&edit=1
ID: 61945
Comment by: ni...@php.net
Reported by:sevenrow2 at yahoo dot com
Summary:array returned from __get method gices a notice when
trying to change a value
Status: Open
Type: Bug
Package:Dynamic loading
Operating System: Windows 7
PHP Version:5.4.2
Block user comment: N
Private report: N
New Comment:
You should define __get to return by reference:
public function &__get($name) { ... }
Modifications of the type $foo->x[0] = 'y' (where ->x is a magic property)
happen by executing roughly the following code:
$array =& $foo->x;
$array[0] = 'y';
If $foo->x is not a reference here though, $array[0] = 'y' will only be able to
change the copied array, not the original one.
In your case you still see the change due to a lucky combination of arrays and
objects. You aren't actually modifying the array, but only the object and
objects behave reference-like by themselves.
---
I'd be inclined to close this as Not A Bug, but there is actually some kind of
bug in here: PHP should see that $foo->x[0]->y = 'z' does not change the
returned array, so no notice should appear. But I'm not sure whether that's
fixable.
Previous Comments:
[2012-05-04 22:33:22] sevenrow2 at yahoo dot com
Description:
I'm using the latest downloadable version of PHP 5.4.2.
See the following code (this code works):
---
vars[$name])) {
$arrObj = new B();
$this->vars[$name] = $arrObj;
}
$obj = $this->vars[$name];
return $obj;
}
}
class B {
public $rolename = 'foo';
}
$a = new A;
var_dump($a);
echo $a->role->rolename.PHP_EOL;
$a->role->rolename = 'test';
echo $a->role->rolename;
?>
-
What happends in this code is that i create a simple object "A". From that
object i try to get the 'role' property. It doesn't exist, so the magic __get()
function is called.
In there i create a B() object and i return the instance of that object. Right
after that i'm trying to access the 'rolename' property of the 'B()' object:
echo $a->role->rolename.PHP_EOL;
$a->role->rolename = 'test';
This works. It successfully echo's the rolename and changes it after that.
-
The problem occurs when i return an array with objects:
vars[$name])) {
$arrObj = array();
$arrObj[] = new B();
$arrObj[] = new B();
$this->vars[$name] = $arrObj;
}
return $this->vars[$name];
}
}
class B {
public $rolename = 'foo';
}
$a = new A;
var_dump($a);
echo $a->role[0]->rolename.PHP_EOL;
$a->role[0]->rolename = 'test';
echo $a->role[0]->rolename;
?>
--
This code gives me the following notice:
"Notice: Indirect modification of overloaded property A::$role has no effect"
Strangely enough it tells me that i can't change the property any more. Or
better yet, it has no effect. The only difference is, is that i get the object
from an array.
The weird thing is though, that it DOES alter the value of the property,
regardless of the notice.
I think the notice shouldn't be displayed in this case.
Test script:
---
vars[$name])) {
$arrObj = array();
$arrObj[] = new B();
$arrObj[] = new B();
$this->vars[$name] = $arrObj;
}
return $this->vars[$name];
}
}
class B {
public $rolename = 'foo';
}
$a = new A;
var_dump($a);
echo $a->role[0]->rolename.PHP_EOL;
$a->role[0]->rolename = 'test';
echo $a->role[0]->rolename;
?>
Expected result:
I expected that $a->role[0]->rolename = 'test'; simply changed the value of
that property, but it generates an unexpected 'notice'.
But: echo $a->role[0]->rolename; does show me that the property was actually
changed, regardless of the notice which tells that it can't be changed.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61945&edit=1
Bug #61964 [Com]: finfo_open with directory causes invalid free
Edit report at https://bugs.php.net/bug.php?id=61964&edit=1
ID: 61964
Comment by: ni...@php.net
Reported by: ni...@php.net
Summary:finfo_open with directory causes invalid free
Status: Open
Type: Bug
Package:Filesystem function related
PHP Version:master-Git-2012-05-06 (Git)
Block user comment: N
Private report: N
New Comment:
Reeze already has a patch which fixes this issue and several related memory
leaks. Though I can't find it anywhere now :/
Previous Comments:
[2012-05-13 10:56:10] larue...@php.net
then I think we can simply prevent directory parameter
[2012-05-09 23:37:07] fel...@php.net
In fact the libmagic code seems not prepared to work with directory, even
alloc'ing the data properly and freeing, it causes memleaks in other parts.
[2012-05-06 14:06:07] larue...@php.net
diff --git a/ext/fileinfo/fileinfo.c b/ext/fileinfo/fileinfo.c
index 2c0e39a..9241e5b 100644
--- a/ext/fileinfo/fileinfo.c
+++ b/ext/fileinfo/fileinfo.c
@@ -315,16 +315,24 @@ PHP_FUNCTION(finfo_open)
if (file_len == 0) {
file = NULL;
} else if (file && *file) { /* user specified file, perform
open_basedir
checks */
+ struct stat sb;
+
if (strlen(file) != file_len) {
FILEINFO_DESTROY_OBJECT(object);
RETURN_FALSE;
}
+
+ if (VCWD_STAT(file, &sb) || !S_ISREG(sb.st_mode)) {
+ FILEINFO_DESTROY_OBJECT(object);
+ RETURN_FALSE;
+ }
+
if (!VCWD_REALPATH(file, resolved_path)) {
FILEINFO_DESTROY_OBJECT(object);
RETURN_FALSE;
}
- file = resolved_path;
+ file = resolved_path;
#if PHP_API_VERSION < 20100412
if ((PG(safe_mode) && (!php_checkuid(file, NULL,
CHECKUID_CHECK_FILE_AND_DIR))) || php_check_open_basedir(file TSRMLS_CC)) {
#else
--------
[2012-05-06 13:39:12] ni...@php.net
Description:
The simple script
,
str=, ptr=0xbfff996c) at malloc.c:6283
#5 0x00a30168 in munmap_chunk (p=) at malloc.c:3540
#6 0x081ffde1 in apprentice_load (ms=0xb717d8f8, magicp=0xbfffa9bc,
nmagicp=0xbfffa9c0, fn=0xb717d150 "/home/nikic/dev/Phuzzy/results",
action=0) at /home/nikic/dev/php-src/ext/fileinfo/libmagic/apprentice.c:814
#7 0x081fecc9 in apprentice_1 (ms=0xb717d8f8,
fn=0xb717d150 "/home/nikic/dev/Phuzzy/results", action=0, mlist=0xb717d1a0)
at /home/nikic/dev/php-src/ext/fileinfo/libmagic/apprentice.c:275
#8 0x081fef8c in file_apprentice (ms=0xb717d8f8,
fn=0xb717d150 "/home/nikic/dev/Phuzzy/results", action=0)
at /home/nikic/dev/php-src/ext/fileinfo/libmagic/apprentice.c:369
#9 0x0820975e in magic_load (ms=0xb717d8f8,
magicfile=0xbfffaaec "/home/nikic/dev/Phuzzy/results")
at /home/nikic/dev/php-src/ext/fileinfo/libmagic/magic.c:308
#10 0x081fdc23 in zif_finfo_open (ht=2, return_value=0xb717c2cc,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0, tsrm_ls=0x8c0f070)
at /home/nikic/dev/php-src/ext/fileinfo/fileinfo.c:345
#11 0x085cf628 in zend_do_fcall_common_helper_SPEC (execute_data=0xb716007c,
tsrm_ls=0x8c0f070) at /home/nikic/dev/php-src/Zend/zend_vm_execute.h:642
#12 0x085d6ddb in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xb716007c,
tsrm_ls=0x8c0f070) at /home/nikic/dev/php-src/Zend/zend_vm_execute.h:2219
#13 0x085cd8d5 in execute (op_array=0xb717cc14, tsrm_ls=0x8c0f070)
at /home/nikic/dev/php-src/Zend/zend_vm_execute.h:410
#14 0x0859202e in zend_execute_scripts (type=8, tsrm_ls=0x8c0f070, retval=0x0,
file_count=3) at /home/nikic/dev/php-src/Zend/zend.c:1272
#15 0x084f4e91 in php_execute_script (primary_file=0xbfffe110,
tsrm_ls=0x8c0f070) at /home/nikic/dev/php-src/main/main.c:2473
#16 0x086dcbc9 in do_cli (argc=2, argv=0xb3b4, tsrm_ls=0x8c0f070)
at /home/nikic/dev/php-src/sapi/cli/php_cli.c:988
#17 0x086de0ed in main (argc=2, argv=0xb3b4)
at /home/nikic/dev/php-src/sapi/cli/php_cli.c:1361
The invalid free occurs in
https://github.com/php/php-src/blob/master/ext/fileinfo/libmagic/apprentice.c#L814.
The code for loading from a directory seems completely broken: The filenames
are snprintf'd into the mfn variable, which is a char[MAXPATHLEN].
For every file that variable is then written into the array, without further
copying: filearr[files++] = mfn;
So basically at the end filearr just contains the last scanned path multiple
times.
Req #47933 [Com]: Allow foreach to iterate multiple arrays/objects similar to for syntax
Edit report at https://bugs.php.net/bug.php?id=47933&edit=1
ID: 47933
Comment by: ni...@php.net
Reported by:e dot sand at elisand dot com
Summary:Allow foreach to iterate multiple arrays/objects
similar to for syntax
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Irrelevant
PHP Version:5.2.9
Block user comment: N
Private report: N
New Comment:
On a side note, this is already possible using MultipleIterator:
http://de3.php.net/MultipleIterator
Previous Comments:
[2009-04-09 07:03:32] e dot sand at elisand dot com
Description:
Using the for construct, you are able to define/utilize multiple variables:
for ($i = 0, $j = 10; $i < 10; $i++, $j--) {...}
I would like to propose that a similar syntax be allowed for the foreach
construct which would allow iterating over multiple arrays/objects at once:
foreach ($array1 as $i => $a, $array2 as $j => $b) {...}
Such syntax and use would be useful when you have multiple arrays that are
related, such as may be found with $_POST data when submitting arrays of
values. For example, a form of inventory data where an id, name and quantity
may be submitted - all in individual arrays but the indexes/keys would relate
across arrays (id[0] -> name[0] -> quantity[0]).
In such an example, you could write a simple foreach iterator as:
foreach ($_POST['id'] as $key => $id, $_POST['name] as $name,
$_POST['quantity'] as $qty) {...}
This would save having to traditionally define $name and $qty within the
foreach loop like so:
$name = $_POST['name'][$key];
$qty = $_POST['quantity'][$key];
That is just a simple example however. As the proposed changes would allow
iterating over multiple arrays at once, it could indeed save considerable lines
of code.
The only issues to debate with regards to this proposition is what happens if
not all arrays being iterated have the same number of members. The other issue
is the syntax, should http://bugs.php.net/bug.php?id=44530&edit=2 be considered
- perhaps using ; instead of , to separate the arrays would be simple enough.
--
Edit this bug report at https://bugs.php.net/bug.php?id=47933&edit=1
Bug #62123 [Com]: Foreach changes the internal pointer of the array strangely
Edit report at https://bugs.php.net/bug.php?id=62123&edit=1 ID: 62123 Comment by: ni...@php.net Reported by:a dot protaskin at gmail dot com Summary:Foreach changes the internal pointer of the array strangely Status: Open Type: Bug Package:Arrays related Operating System: Linux PHP Version:5.4.3 Block user comment: N Private report: N New Comment: See http://stackoverflow.com/a/8263425/385378 for an explanation. Previous Comments: [2012-05-23 13:23:38] a dot protaskin at gmail dot com Description: Traversing the array changes once the internal pointer by 1. Traversing the array by link changes the internal pointer just as with each(). Test script: --- https://bugs.php.net/bug.php?id=62123&edit=1
Bug #62110 [Com]: Foreach creates a copy of the array passed by value in function
Edit report at https://bugs.php.net/bug.php?id=62110&edit=1 ID: 62110 Comment by: ni...@php.net Reported by:a dot protaskin at gmail dot com Summary:Foreach creates a copy of the array passed by value in function Status: Open Type: Bug Package:Performance problem Operating System: Arch Linux PHP Version:5.4.3 Block user comment: N Private report: N New Comment: The foreach loop changes the internal array pointer. If the array zval wouldn't be separated the loop thus would thus affect he array which was passed by value, which is obviously not acceptable. Previous Comments: [2012-05-22 19:56:06] a dot protaskin at gmail dot com Description: I also tried to execute this code on PHP 5.3.13 and PHP 5.2.17 with same result. All options are default. Test script: --- http://pastebin.com/caczCxuD Expected result: Start: 786432 Inner by_reference: 786432 Inner foreach: 786432 After by_reference: 786432 Inner by_value: 786432 Inner foreach: 786432 After by_value: 786432 Actual result: -- Start: 786432 Inner by_reference: 786432 Inner foreach: 786432 After by_reference: 786432 Inner by_value: 786432 Inner foreach: 1310720 After by_value: 104857 -- Edit this bug report at https://bugs.php.net/bug.php?id=62110&edit=1
Bug #62182 [Com]: Default Parameter not to be $_GET or $_POST
Edit report at https://bugs.php.net/bug.php?id=62182&edit=1
ID: 62182
Comment by: ni...@php.net
Reported by:noel_fb at hotmail dot com
Summary:Default Parameter not to be $_GET or $_POST
Status: Open
Type: Bug
Package:*General Issues
Operating System: Red Hat
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
This has nothing to do with $_GET or $_POST. Default arguments simply can only
be static scalars, variables are not allowed in general.
Previous Comments:
[2012-05-29 11:56:00] noel_fb at hotmail dot com
Description:
Hello.
Try:
function prueba($metodos = array($_GET, $_POST)){
}
or
function prueba($metodos = array($_GET)){
}
ERROR:
Parse error: syntax error, unexpected T_VARIABLE, expecting ')' in
/var/www/html/app/xxx/xxx.php on line xx
Test script:
---
Try:
function prueba($metodos = array($_GET, $_POST)){
}
or
function prueba($metodos = array($_GET)){
}
ERROR:
Parse error: syntax error, unexpected T_VARIABLE, expecting ')' in
/var/www/html/app/xxx/xxx.php on line xx
Expected result:
Not error
--
Edit this bug report at https://bugs.php.net/bug.php?id=62182&edit=1
[PHP-BUG] Bug #62210 [NEW]: Exceptions can leak temporary variables
From: nikic Operating system: PHP version: Irrelevant Package: Scripting Engine problem Bug Type: Bug Bug description:Exceptions can leak temporary variables Description: The script https://bugs.php.net/bug.php?id=62210&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62210&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62210&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62210&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62210&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62210&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62210&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62210&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62210&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62210&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62210&r=support Expected behavior: https://bugs.php.net/fix.php?id=62210&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62210&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62210&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62210&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62210&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62210&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62210&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62210&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62210&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62210&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62210&r=mysqlcfg
Req #62257 [Com]: Allow variables in class create
Edit report at https://bugs.php.net/bug.php?id=62257&edit=1
ID: 62257
Comment by: ni...@php.net
Reported by:valentiny510 at yahoo dot es
Summary:Allow variables in class create
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: XP
PHP Version:5.4.3
Block user comment: N
Private report: N
New Comment:
If you want to shorten long names make use of the namespacing support
introduced in 5.3. Simply write
use SomeVery\VeryLong\NameAndMore as ShortName;
and you're done. You can also do this programmatically using class_alias().
Previous Comments:
[2012-06-08 01:20:34] valentiny510 at yahoo dot es
P.S. Not only for long names.. but also for autoloading/extending multiple
classes.. now I let you to imaginate..
[2012-06-08 01:08:33] valentiny510 at yahoo dot es
Description:
I think may be very useful sometimes allowing the use of variables when create
some class like this:
$class = 'test';
class $class { }
Sometimes when working with some cms/framework etc.. they have
a_very_very_very_long_name_for some_classes and will be more easy (depends of
situation) to have an array with shorten name. Ex:
$short_names = array (
'short1' => 'a_very_long_name_of_some_class',
'short2' => 'another_very_long_name');
foreach ($short_names as $short => $long)
class $short extends $long { }
/*endforeach*/;
--
Edit this bug report at https://bugs.php.net/bug.php?id=62257&edit=1
Bug #62303 [Com]: ReflectionClass, getMethods(), getName() empty
Edit report at https://bugs.php.net/bug.php?id=62303&edit=1
ID: 62303
Comment by: ni...@php.net
Reported by:v at roxori dot com
Summary:ReflectionClass, getMethods(), getName() empty
Status: Open
Type: Bug
Package:Reflection related
Operating System: FreeBSD9
PHP Version:5.4.3
Block user comment: N
Private report: N
New Comment:
I can't reproduce this: http://3v4l.org/6cvK8#v500
Seems to behave the same on all versions, with no change in between.
Maybe this is OS specific (or specific to something else in your env).
Previous Comments:
[2012-06-12 21:01:45] v at roxori dot com
Description:
After upgrading PHP to 5.4.3 no longer return the name of the method.
Correspondingly, the library stopped working, namely Zend. Now the issue Fatal
error: Uncaught exception 'Zend_Amf_Server_Exception' with message 'Duplicate
method registered: Having sorted out, I realized that the code does not return
the
name of the method. In PHP 5.3 all was ok.
---
>From manual page: http://www.php.net/reflectionclass.getname#refsect1-
reflectionclass.getname-description
---
Test script:
---
class Foo {
function first(){
}
function second(){
}
}
$foo = new Foo();
$reflect = new ReflectionClass($foo);
$props = $reflect->getMethods();
foreach ($props as $prop) {
print $prop->getName() . "\n";
}
Expected result:
first
second
Actual result:
--
(empty)
--
Edit this bug report at https://bugs.php.net/bug.php?id=62303&edit=1
