Doc->Req #54405 [Opn]: FETCH_GROUP always operates on first column
Edit report at https://bugs.php.net/bug.php?id=54405&edit=1 ID: 54405 Updated by: frozenf...@php.net Reported by:php at bucksvsbytes dot com Summary:FETCH_GROUP always operates on first column Status: Open -Type: Documentation Problem +Type: Feature/Change Request -Package:Documentation problem +Package:PDO related PHP Version:Irrelevant Block user comment: N Private report: N New Comment: This seems like more of a bug/feature request, since the current behavior is near useless. After (if) it's been patched, please change this bug to a documentation problem bug type, so the change and new behavior can be documented. Previous Comments: [2011-05-02 01:29:30] jinmoku at hotmail dot com Or maybe add a fetch.column for FETCH_GROUP (see path) [2011-03-28 04:51:11] php at bucksvsbytes dot com Description: --- >From manual page: http://www.php.net/pdostatement.fetchall#Parameters --- The following statement is misleading/incorrect, "To return an associative array grouped by the values of a specified column, bitwise-OR PDO::FETCH_COLUMN with PDO::FETCH_GROUP." It's apparent that FETCH_GROUP only groups on the first query column, so "a specified" should be replaced with "the first". -- Edit this bug report at https://bugs.php.net/bug.php?id=54405&edit=1
[PHP-BUG] Bug #60445 [NEW]: Getting ext/standard/user_fliter.lo is not a valid libtool object erro
From: Operating system: RHEL 6.1 for POWER7 PHP version: 5.3.8 Package: Compile Failure Bug Type: Bug Bug description:Getting ext/standard/user_fliter.lo is not a valid libtool object erro Description: Building on an IBM Power platform running RHEL 6.1 for power7. I am trying to build a simple php with the following options: $ configure --with-apxs2=/etc/apache2/bin/apxs configure runs fine but the build fails during the make with the following error. The last step and the error is displayed below: /bin/sh /usr/local/sw/php/libtool --silent --preserve-dup-deps --mode=link gcc - I/usr/include -O3 -mcpu=power7 -mtune=power7 -m32 -fvisibility=hidden -rpath /usr/local/sw/php/libs libtool: link: `ext/standard/user_filters.lo' is not a valid libtool object make: *** [libphp5.la] Error 1 Test script: --- $ configure --with-apxs2=/etc/apache2/bin/apxs $ make $ make install Fails on make Expected result: Should make correctly. Actual result: -- /bin/sh /usr/local/sw/php/libtool --silent --preserve-dup-deps --mode=link gcc - I/usr/include -O3 -mcpu=power7 -mtune=power7 -m32 -fvisibility=hidden -rpath /usr/local/sw/php/libs -avoid-version -module -L/usr/local/lib -m32 -R /usr/local/lib ext/date/php_date.lo ext/date/lib/astro.lo ext/date/lib/dow.lo ext/date/lib/parse_date.lo ext/date/lib/parse_tz.lo ext/date/lib/timelib.lo ext/date/lib/tm2unixtime.lo ext/date/lib/unixtime2tm.lo ext/date/lib/parse_iso_intervals.lo ext/date/lib/interval.lo ext/ereg/ereg.lo ext/ereg/regex/regcomp.lo ext/ereg/regex/regexec.lo ext/ereg/regex/regerror.lo ext/ereg/regex/regfree.lo ext/libxml/libxml.lo ext/pcre/pcrelib/pcre_chartables.lo ext/pcre/pcrelib/pcre_ucd.lo ext/pcre/pcrelib/pcre_compile.lo ext/pcre/pcrelib/pcre_config.lo ext/pcre/pcrelib/pcre_exec.lo ext/pcre/pcrelib/pcre_fullinfo.lo ext/pcre/pcrelib/pcre_get.lo ext/pcre/pcrelib/pcre_globals.lo ext/pcre/pcrelib/pcre_info.lo ext/pcre/pcrelib/pcre_maketables.lo ext/pcre/pcrelib/pcre_newline.lo ext/pcre/pcrelib/pcre_ord2utf8.lo ext/pcre/pcrelib/pcre_refcount.lo ext/pcre/pcrelib/pcre_study.lo ext/pcre/pcrelib/pcre_tables.lo ext/pcre/pcrelib/pcre_try_flipped.lo ext/pcre/pcrelib/pcre_valid_utf8.lo ext/pcre/pcrelib/pcre_version.lo ext/pcre/pcrelib/pcre_xclass.lo ext/pcre/php_pcre.lo ext/sqlite3/sqlite3.lo ext/sqlite3/libsqlite/sqlite3.lo ext/ctype/ctype.lo ext/dom/php_dom.lo ext/dom/attr.lo ext/dom/document.lo ext/dom/domerrorhandler.lo ext/dom/domstringlist.lo ext/dom/domexception.lo ext/dom/namelist.lo ext/dom/processinginstruction.lo ext/dom/cdatasection.lo ext/dom/documentfragment.lo ext/dom/domimplementation.lo ext/dom/element.lo ext/dom/node.lo ext/dom/string_extend.lo ext/dom/characterdata.lo ext/dom/documenttype.lo ext/dom/domimplementationlist.lo ext/dom/entity.lo ext/dom/nodelist.lo ext/dom/text.lo ext/dom/comment.lo ext/dom/domconfiguration.lo ext/dom/domimplementationsource.lo ext/dom/entityreference.lo ext/dom/notation.lo ext/dom/xpath.lo ext/dom/dom_iterators.lo ext/dom/typeinfo.lo ext/dom/domerror.lo ext/dom/domlocator.lo ext/dom/namednodemap.lo ext/dom/userdatahandler.lo ext/fileinfo/fileinfo.lo ext/fileinfo/libmagic/apprentice.lo ext/fileinfo/libmagic/apptype.lo ext/fileinfo/libmagic/ascmagic.lo ext/fileinfo/libmagic/cdf.lo ext/fileinfo/libmagic/cdf_time.lo ext/fileinfo/libmagic/compress.lo ext/fileinfo/libmagic/encoding.lo ext/fileinfo/libmagic/fsmagic.lo ext/fileinfo/libmagic/funcs.lo ext/fileinfo/libmagic/is_tar.lo ext/fileinfo/libmagic/magic.lo ext/fileinfo/libmagic/print.lo ext/fileinfo/libmagic/readcdf.lo ext/fileinfo/libmagic/readelf.lo ext/fileinfo/libmagic/softmagic.lo ext/filter/filter.lo ext/filter/sanitizing_filters.lo ext/filter/logical_filters.lo ext/filter/callback_filter.lo ext/hash/hash.lo ext/hash/hash_md.lo ext/hash/hash_sha.lo ext/hash/hash_ripemd.lo ext/hash/hash_haval.lo ext/hash/hash_tiger.lo ext/hash/hash_gost.lo ext/hash/hash_snefru.lo ext/hash/hash_whirlpool.lo ext/hash/hash_adler32.lo ext/hash/hash_crc32.lo ext/hash/hash_salsa.lo ext/iconv/iconv.lo ext/json/json.lo ext/json/utf8_to_utf16.lo ext/json/utf8_decode.lo ext/json/JSON_parser.lo ext/pdo/pdo.lo ext/pdo/pdo_dbh.lo ext/pdo/pdo_stmt.lo ext/pdo/pdo_sql_parser.lo ext/pdo/pdo_sqlstate.lo ext/pdo_sqlite/pdo_sqlite.lo ext/pdo_sqlite/sqlite_driver.lo ext/pdo_sqlite/sqlite_statement.lo ext/phar/util.lo ext/phar/tar.lo ext/phar/zip.lo ext/phar/stream.lo ext/phar/func_interceptors.lo ext/phar/dirstream.lo ext/phar/phar.lo ext/phar/phar_object.lo ext/phar/phar_path_check.lo ext/posix/posix.lo ext/reflection/php_reflection.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo ext/simplexml/simplexml.lo ext/simplexml/sxe.lo ext/spl/php_spl.lo ext/spl/spl_functions.lo ext/spl/spl_engine.lo ext/spl/spl_iterators.lo ext/spl/spl_array.lo ext/spl/spl_directory.lo ext/spl/spl_exceptions.lo ext/spl/spl_o
Bug #60362 [PATCH]: non-existent sub-sub keys should not have values
Edit report at https://bugs.php.net/bug.php?id=60362&edit=1 ID: 60362 Patch added by: larue...@php.net Reported by:danielc at analysisandsolutions dot com Summary:non-existent sub-sub keys should not have values Status: Open Type: Bug Package:Arrays related Operating System: linux PHP Version:5.4SVN-2011-11-23 (SVN) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: string_offset_trigger_notice.patch Revision: 1323062240 URL: https://bugs.php.net/patch-display.php?bug=60362&patch=string_offset_trigger_notice.patch&revision=1323062240 Previous Comments: [2011-12-04 17:27:28] larue...@php.net submit a new patch, which only trigger notice when string offset cast occurred. [2011-12-04 17:26:41] larue...@php.net The following patch has been added/updated: Patch Name: string_offset_trigger_notice.patch Revision: 1323019601 URL: https://bugs.php.net/patch-display.php?bug=60362&patch=string_offset_trigger_notice.patch&revision=1323019601 [2011-12-04 16:43:41] larue...@php.net update patch, only change the code style, and fix one test faild, thanks [2011-12-04 16:43:01] larue...@php.net The following patch has been added/updated: Patch Name: fix_disabling_bad_string_offsets Revision: 1323016981 URL: https://bugs.php.net/patch-display.php?bug=60362&patch=fix_disabling_bad_string_offsets&revision=1323016981 [2011-12-04 12:52:52] alan at akbkhome dot com This is the test output after the changes: - most of this makes sense - string offsets of strings are now invalid, and the dereferencing of strings with numerical indexes is 'fixed' and a behaviour change. BEHAVIOR CHANGED: sub-key 'non_existent' is not set. expected: sub-key 1 is set: string(1) "o" --- good: sub-sub-key 'sub_sub' is not set. BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) "o" --- BEHAVIOR CHANGED: sub-key 'non_existent' is empty. expected: sub-key 1 is NOT empty: string(1) "o" --- good: sub-sub-key 'sub_sub' is empty. BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) "o" 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=60362 -- Edit this bug report at https://bugs.php.net/bug.php?id=60362&edit=1
[PHP-BUG] Bug #60444 [NEW]: Segmentation fault with include & class extending
From: Operating system: Linux Debian PHP version: 5.4SVN-2011-12-05 (snap) Package: Reproducible crash Bug Type: Bug Bug description:Segmentation fault with include & class extending Description: Crash on combination of class & include & extends. Test script: --- a.php: https://bugs.php.net/bug.php?id=60444&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60444&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60444&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60444&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60444&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60444&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60444&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60444&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60444&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60444&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60444&r=support Expected behavior: https://bugs.php.net/fix.php?id=60444&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60444&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60444&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60444&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60444&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60444&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60444&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60444&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60444&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60444&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60444&r=mysqlcfg
Req #54537 [Opn->Csd]: production value for html_errors should be On
Edit report at https://bugs.php.net/bug.php?id=54537&edit=1
ID: 54537
Updated by: tyr...@php.net
Reported by:tyra3l at gmail dot com
Summary:production value for html_errors should be On
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package:*Configuration Issues
PHP Version:5.3.6
-Assigned To:
+Assigned To:tyrael
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
fixed in 5.4:
https://wiki.php.net/rfc/error-formatting-for-developers
http://svn.php.net/viewvc?view=revision&revision=314761
Previous Comments:
[2011-04-15 22:31:33] tyra3l at gmail dot com
probably you know, but you can re-enable html_errors for cli via ini_set:
http://www.php.net/manual/en/features.commandline.differences.php
for example:
php -d display_errors=1 -d error_reporting=-1 -r 'ini_set("html_errors",
1);trigger_error("foo", E_USER_NOTICE);'
Tyrael
[2011-04-15 22:16:21] tyra3l at gmail dot com
sorry, I can't follow you.
"Is a dynamic plain text web page that hard to imagine?"
no, but the majority of the php sites out there use html as the primary output
type.
you can turn off the html_errors if you are dealing with plain text files.
"I know the CLI SAPI has html_errors = 0 hard coded in but why force people
to turn off an option that provides little to no benefit..."
so only the apache SAPI would be affected, where the majority of the users use
html output.
but I think that this option should affect anything in a production system,
because you turn off the error_reporting in production (and PHP also suggests
that, so any distribution which follows the suggestions of the php.ini-* files
wouldn't be affected by this change. at all)
and both error_reporting and html_errors is enabled in the php.ini-development,
so for the text/plain people that would be a problem also.
Tyrael
[2011-04-15 21:47:55] dtajchre...@php.net
Is a dynamic plain text web page that hard to imagine? What about non browser
output? I know the CLI SAPI has html_errors = 0 hard coded in but why force
people
to turn off an option that provides little to no benefit...
[2011-04-15 17:04:24] der...@php.net
I agree. There is no reason why html_errors should be off in any case.
Especially because the reasoning is non-sense.
[2011-04-15 12:18:12] tyra3l at gmail dot com
Description:
I've noticed, that we suggest setting the html_errors in production to Off,
which
is an odd thing: in production one should display errors, but if he does, then
I
can't see why would be more appropriate not to use html errors.
could you elaborate on this please?
--
Edit this bug report at https://bugs.php.net/bug.php?id=54537&edit=1
Req #54032 [Opn->Csd]: ability to to handle Class not found error
Edit report at https://bugs.php.net/bug.php?id=54032&edit=1 ID: 54032 Updated by: tyr...@php.net Reported by:tyra3l at gmail dot com Summary:ability to to handle Class not found error -Status: Open +Status: Closed Type: Feature/Change Request Package:SPL related PHP Version:5.3.5 -Assigned To: +Assigned To:tyrael Block user comment: N Private report: N New Comment: if I can come up with something, I will write an RFC instead. Previous Comments: [2011-03-29 09:39:28] tyra3l at gmail dot com after some sleep and a little bit thinking, I think that the best solution would be to introduce a new Exception type, which will be thrown if the execution of the autoload callbacks doesn't successfully load the class. what do you think? Tyrael [2011-02-17 00:15:36] tyra3l at gmail dot com *exists -> exit *exection -> execution * spl autoload callbacks was executed -> spl autoload callbacks was executed without finding the class * I cannot continue the normal execution flow -> I couldn't continue the normal execution flow * from a higher level -> at a higher level sorry, its getting late, and my english skill degrades with sleep deprivation [2011-02-17 00:11:01] tyra3l at gmail dot com Description: currently you can throw an exception from the autoloader, hence if you can't find a class, your application can gracefully exists, instead of exiting via the class not found fatal error. my problem is, that I would like to use multiple autoloader (for example in a project which uses multiple component, or framework), but in this case, I can't throw an Exception from my autoloader, because maybe the other autoloaders could load the class. if I'm sure that I will register the last autoloader, the this isn't a problem(my last autoloader will throw the Exception on missing class), but maybe I have to load a component late of the exection. it would be cool, if I could somehow register a callback which will be called, when the spl autoload callbacks was executed, but the class couldn't be loaded of course, from this callback, I cannot continue the normal execution flow, however I can log the error, and let the callback return and get the class not found fatal error, or throw an Exception, and handle/log the error from a higher level. -- Edit this bug report at https://bugs.php.net/bug.php?id=54032&edit=1
Bug #54908 [Opn->Fbk]: DBLIB segfaults when GROUPing with 0 rows for prepared statements
Edit report at https://bugs.php.net/bug.php?id=54908&edit=1
ID: 54908
Updated by: ssuffic...@php.net
Reported by:StevenHadfield at letu dot edu
Summary:DBLIB segfaults when GROUPing with 0 rows for
prepared statements
-Status: Open
+Status: Feedback
Type: Bug
Package:PDO related
Operating System: Fedora Rawhide
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
PDO_DBLIB has been significantly redesigned in PHP 5.4. Many memory allocations
were removed possibly resolving this issue.
Previous Comments:
[2011-05-23 15:25:45] StevenHadfield at letu dot edu
gdb backtrace:
#0 _zend_mm_free_int (heap=0xb2c310, p=0xe1b868) at
/usr/src/debug/php-5.3.6/Zend/zend_alloc.c:2028
#1 0x7fffef1d1b1e in free_statement (stmt=0xe1bb70) at
/usr/src/debug/php-5.3.6/ext/pdo/pdo_stmt.c:2410
#2 0x005d0f3f in zend_objects_store_del_ref_by_handle_ex (handle=2,
handlers=)
at /usr/src/debug/php-5.3.6/Zend/zend_objects_API.c:220
#3 0x005d0f63 in zend_objects_store_del_ref (zobject=0xe1aa08) at
/usr/src/debug/php-5.3.6/Zend/zend_objects_API.c:172
#4 0x005a09f2 in _zval_dtor (zvalue=) at
/usr/src/debug/php-5.3.6/Zend/zend_variables.h:35
#5 _zval_ptr_dtor (zval_ptr=0xe1c170) at
/usr/src/debug/php-5.3.6/Zend/zend_execute_API.c:443
#6 _zval_ptr_dtor (zval_ptr=0xe1c170) at
/usr/src/debug/php-5.3.6/Zend/zend_execute_API.c:432
#7 0x005bb931 in zend_hash_del_key_or_index (ht=0x939ec8,
arKey=, nKeyLength=, h=,
flag=) at /usr/src/debug/php-5.3.6/Zend/zend_hash.c:500
#8 0x0062b36a in ZEND_UNSET_VAR_SPEC_CV_HANDLER
(execute_data=0x7fffeb09c050) at
/usr/src/debug/php-5.3.6/Zend/zend_vm_execute.h:22511
#9 0x005d1e2b in execute (op_array=0xe1b260) at
/usr/src/debug/php-5.3.6/Zend/zend_vm_execute.h:107
#10 0x71e78d6d in xdebug_execute (op_array=0xe1b260) at
/usr/src/debug/php-pecl-xdebug-2.1.1/xdebug-2.1.1/xdebug.c:1268
#11 0x005affb0 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/debug/php-5.3.6/Zend/zend.c:1194
#12 0x0055d3b3 in php_execute_script (primary_file=0x7fffdd20) at
/usr/src/debug/php-5.3.6/main/main.c:2268
#13 0x0042486e in main (argc=2, argv=0x7fffdf28) at
/usr/src/debug/php-5.3.6/sapi/cli/php_cli.c:1193
[2011-05-23 15:21:06] fel...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
[2011-05-23 15:18:04] StevenHadfield at letu dot edu
Description:
I haven't fully figured out the cause of this problem, but for what I can
narrow it down, it's a bit of a remote case.
What I am experiencing is odd behavior when doing a PDO(DBLIB) prepared
statement on a SELECT query with a GROUP BY clause. As far as I can tell, when
the query would have returned 0 results, the query returns an empty array, but
the next time the query is run, I get the following result (regardless of what
the data should actually be):
array(1) {
[0]=>
array(2) {
["!"]=>
NULL
[0]=>
NULL
}
}
After this occurs, any attempt (whether explicit or implicit) to unset the
statement results in a segfault in Zend/zend_alloc.c:2028:
if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
I have also found that this only happens when the first execution of the
prepared statement results in a 0 row query. If the order of the execution in
the test script below is reversed so that a result is returned, the prepared
statement works fine from then on.
Another specific of this bug is that it only occurs with the GROUP BY clause.
The query will work fine if I have an aggregate function, but do not have the
GROUP BY column specified.
I have tried the query in a different query tool, and it works fine.
I also tried the script with the php5.3-201105231230 snapshot, but was still
having the issue.
This problem is similar to Bug #40639, but my problem seems more narrow in
focus. I also do not receive the same segfault as the other bug.
Test script:
---
prepare('SELECT COALESCE(SUM(tblTransaction.Amount), 0) FROM
tblTransaction INNER JOIN tblDiscount ON tblTransaction.Trans
Bug #60122 [Opn]: Many multi-row statements gives wrong result
Edit report at https://bugs.php.net/bug.php?id=60122&edit=1
ID: 60122
Updated by: ssuffic...@php.net
Reported by:armiksos at gmail dot com
Summary:Many multi-row statements gives wrong result
Status: Open
Type: Bug
Package:PDO related
Operating System: windows 7
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Which driver are you using (i.e. MySQL, PostgreSQL, DBLIB, SqlServer?)
Previous Comments:
[2011-10-24 14:49:39] armiksos at gmail dot com
Description:
If you create two query of multi-row statements in one .php file and you assign
them
to the same variable after processing one of them, the second query will give
only
result of only ONE statement.
If you assign the result of query to another variable, the result will be
correct.
So$another_var_name = $conn->query("SELECT 1 as one; SELECT 2 as two;
SELECT 3
as three;");
will work in Test script, otherwise result will be wrong.
Test script:
---
$q = $conn->query("SELECT 1 as one; SELECT 2 as two; SELECT 3 as
three;");
do
{
$r=$q->fetchAll(PDO::FETCH_ASSOC);
echo "";
print_r($r);
}while($q->nextRowset());
$q = $conn->query("SELECT 1 as one; SELECT 2 as two; SELECT 3 as
three;");
do
{
$r=$q->fetchAll(PDO::FETCH_ASSOC);
echo "";
print_r($r);
}while($q->nextRowset());
Expected result:
Array ( [0] => Array ( [one] => 1 ) )
Array ( [0] => Array ( [two] => 2 ) )
Array ( [0] => Array ( [three] => 3 ) )
Array ( [0] => Array ( [one] => 1 ) )
Array ( [0] => Array ( [two] => 2 ) )
Array ( [0] => Array ( [three] => 3 ) )
Actual result:
--
Array ( [0] => Array ( [one] => 1 ) )
Array ( [0] => Array ( [two] => 2 ) )
Array ( [0] => Array ( [three] => 3 ) )
Array ( [0] => Array ( [one] => 1 ) )
--
Edit this bug report at https://bugs.php.net/bug.php?id=60122&edit=1
Bug #60362 [Com]: non-existent sub-sub keys should not have values
Edit report at https://bugs.php.net/bug.php?id=60362&edit=1
ID: 60362
Comment by: larue...@php.net
Reported by:danielc at analysisandsolutions dot com
Summary:non-existent sub-sub keys should not have values
Status: Open
Type: Bug
Package:Arrays related
Operating System: linux
PHP Version:5.4SVN-2011-11-23 (SVN)
Block user comment: N
Private report: N
New Comment:
submit a new patch, which only trigger notice when string offset cast occurred.
Previous Comments:
[2011-12-04 17:26:41] larue...@php.net
The following patch has been added/updated:
Patch Name: string_offset_trigger_notice.patch
Revision: 1323019601
URL:
https://bugs.php.net/patch-display.php?bug=60362&patch=string_offset_trigger_notice.patch&revision=1323019601
[2011-12-04 16:43:41] larue...@php.net
update patch, only change the code style, and fix one test faild, thanks
[2011-12-04 16:43:01] larue...@php.net
The following patch has been added/updated:
Patch Name: fix_disabling_bad_string_offsets
Revision: 1323016981
URL:
https://bugs.php.net/patch-display.php?bug=60362&patch=fix_disabling_bad_string_offsets&revision=1323016981
[2011-12-04 12:52:52] alan at akbkhome dot com
This is the test output after the changes:
- most of this makes sense - string offsets of strings are now invalid, and the
dereferencing of strings with numerical indexes is 'fixed' and a behaviour
change.
BEHAVIOR CHANGED: sub-key 'non_existent' is not set.
expected: sub-key 1 is set: string(1) "o"
---
good: sub-sub-key 'sub_sub' is not set.
BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) "o"
---
BEHAVIOR CHANGED: sub-key 'non_existent' is empty.
expected: sub-key 1 is NOT empty: string(1) "o"
---
good: sub-sub-key 'sub_sub' is empty.
BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) "o"
[2011-11-23 01:37:51] danielc at analysisandsolutions dot com
Description:
In an array, a sub-sub-key of an existing key is now returning a letter of the
value indexed by the main key. This is a regression in 5.4. PHP 5.3 still
operates as expected. I suspect this is related to the array dereferencing
changes.
Test script:
---
$arr = array('exists' => 'foo');
if (isset($arr['exists']['non_existent'])) {
echo "expected: sub-key 'non_existent' is set: ";
var_dump($arr['exists']['non_existent']);
} else {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is not set.\n";
}
if (isset($arr['exists'][1])) {
echo "expected: sub-key 1 is set: ";
var_dump($arr['exists'][1]);
} else {
echo "BEHAVIOR CHANGED: sub-key 1 is not set.\n";
}
echo "---\n";
if (isset($arr['exists']['non_existent']['sub_sub'])) {
echo "BEHAVIOR CHANGED: sub-key 'sub_sub' is set: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
} else {
echo "good: sub-sub-key 'sub_sub' is not set.\n";
}
if (isset($arr['exists'][1][0])) {
echo "BEHAVIOR CHANGED: sub-sub-key 0 is set: ";
var_dump($arr['exists'][1][0]);
} else {
echo "good: sub-sub-key 0 is not set.\n";
}
echo "---\n";
if (empty($arr['exists']['non_existent'])) {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is empty.\n";
} else {
echo "expected: sub-key 'non_existent' is not empty: ";
var_dump($arr['exists']['non_existent']);
}
if (empty($arr['exists'][1])) {
echo "BEHAVIOR CHANGED: sub-key 1 is empty.\n";
} else {
echo "expected: sub-key 1 is NOT empty: ";
var_dump($arr['exists'][1]);
}
echo "---\n";
if (empty($arr['exists']['non_existent']['sub_sub'])) {
echo "good: sub-sub-key 'sub_sub' is empty.\n";
} else {
echo "BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
}
if (empty($arr['exists'][1][0])) {
echo "good: sub-sub-key 0 is empty.\n";
} else {
echo "BEHAVIOR CHANGED: sub-sub-key 0 is not empty: ";
var_dump($arr['exists'][1][0]);
}
Expected result:
expected: sub-key 'non_existent' is set: string(1) "f"
expected: sub-key 1 is set: string(1) "o"
---
good: sub-sub-key 'sub_sub' is not set.
good: sub-sub-key 0 is not set.
---
expected: sub-key 'non_existent' is not empty: string(1) "f"
expected: sub-key 1 is NOT empty: string(1) "o"
---
good: sub-sub-key 'sub_sub' is empty.
good: sub-sub-key 0 is empty.
Actual result:
--
expected: sub-key 'non_existent' is set: string(1) "f"
expected: sub-key 1 is se
Bug #60362 [PATCH]: non-existent sub-sub keys should not have values
Edit report at https://bugs.php.net/bug.php?id=60362&edit=1
ID: 60362
Patch added by: larue...@php.net
Reported by:danielc at analysisandsolutions dot com
Summary:non-existent sub-sub keys should not have values
Status: Open
Type: Bug
Package:Arrays related
Operating System: linux
PHP Version:5.4SVN-2011-11-23 (SVN)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: string_offset_trigger_notice.patch
Revision: 1323019601
URL:
https://bugs.php.net/patch-display.php?bug=60362&patch=string_offset_trigger_notice.patch&revision=1323019601
Previous Comments:
[2011-12-04 16:43:41] larue...@php.net
update patch, only change the code style, and fix one test faild, thanks
[2011-12-04 16:43:01] larue...@php.net
The following patch has been added/updated:
Patch Name: fix_disabling_bad_string_offsets
Revision: 1323016981
URL:
https://bugs.php.net/patch-display.php?bug=60362&patch=fix_disabling_bad_string_offsets&revision=1323016981
[2011-12-04 12:52:52] alan at akbkhome dot com
This is the test output after the changes:
- most of this makes sense - string offsets of strings are now invalid, and the
dereferencing of strings with numerical indexes is 'fixed' and a behaviour
change.
BEHAVIOR CHANGED: sub-key 'non_existent' is not set.
expected: sub-key 1 is set: string(1) "o"
---
good: sub-sub-key 'sub_sub' is not set.
BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) "o"
---
BEHAVIOR CHANGED: sub-key 'non_existent' is empty.
expected: sub-key 1 is NOT empty: string(1) "o"
---
good: sub-sub-key 'sub_sub' is empty.
BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) "o"
[2011-11-23 01:37:51] danielc at analysisandsolutions dot com
Description:
In an array, a sub-sub-key of an existing key is now returning a letter of the
value indexed by the main key. This is a regression in 5.4. PHP 5.3 still
operates as expected. I suspect this is related to the array dereferencing
changes.
Test script:
---
$arr = array('exists' => 'foo');
if (isset($arr['exists']['non_existent'])) {
echo "expected: sub-key 'non_existent' is set: ";
var_dump($arr['exists']['non_existent']);
} else {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is not set.\n";
}
if (isset($arr['exists'][1])) {
echo "expected: sub-key 1 is set: ";
var_dump($arr['exists'][1]);
} else {
echo "BEHAVIOR CHANGED: sub-key 1 is not set.\n";
}
echo "---\n";
if (isset($arr['exists']['non_existent']['sub_sub'])) {
echo "BEHAVIOR CHANGED: sub-key 'sub_sub' is set: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
} else {
echo "good: sub-sub-key 'sub_sub' is not set.\n";
}
if (isset($arr['exists'][1][0])) {
echo "BEHAVIOR CHANGED: sub-sub-key 0 is set: ";
var_dump($arr['exists'][1][0]);
} else {
echo "good: sub-sub-key 0 is not set.\n";
}
echo "---\n";
if (empty($arr['exists']['non_existent'])) {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is empty.\n";
} else {
echo "expected: sub-key 'non_existent' is not empty: ";
var_dump($arr['exists']['non_existent']);
}
if (empty($arr['exists'][1])) {
echo "BEHAVIOR CHANGED: sub-key 1 is empty.\n";
} else {
echo "expected: sub-key 1 is NOT empty: ";
var_dump($arr['exists'][1]);
}
echo "---\n";
if (empty($arr['exists']['non_existent']['sub_sub'])) {
echo "good: sub-sub-key 'sub_sub' is empty.\n";
} else {
echo "BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
}
if (empty($arr['exists'][1][0])) {
echo "good: sub-sub-key 0 is empty.\n";
} else {
echo "BEHAVIOR CHANGED: sub-sub-key 0 is not empty: ";
var_dump($arr['exists'][1][0]);
}
Expected result:
expected: sub-key 'non_existent' is set: string(1) "f"
expected: sub-key 1 is set: string(1) "o"
---
good: sub-sub-key 'sub_sub' is not set.
good: sub-sub-key 0 is not set.
---
expected: sub-key 'non_existent' is not empty: string(1) "f"
expected: sub-key 1 is NOT empty: string(1) "o"
---
good: sub-sub-key 'sub_sub' is empty.
good: sub-sub-key 0 is empty.
Actual result:
--
expected: sub-key 'non_existent' is set: string(1) "f"
expected: sub-key 1 is set: string(1) "o"
---
BEHAVIOR CHANGED: sub-key 'sub_sub' is set: string(1) "f"
BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) "o"
---
expected: sub-key 'non_ex
Bug #60362 [Com]: non-existent sub-sub keys should not have values
Edit report at https://bugs.php.net/bug.php?id=60362&edit=1
ID: 60362
Comment by: larue...@php.net
Reported by:danielc at analysisandsolutions dot com
Summary:non-existent sub-sub keys should not have values
Status: Open
Type: Bug
Package:Arrays related
Operating System: linux
PHP Version:5.4SVN-2011-11-23 (SVN)
Block user comment: N
Private report: N
New Comment:
update patch, only change the code style, and fix one test faild, thanks
Previous Comments:
[2011-12-04 16:43:01] larue...@php.net
The following patch has been added/updated:
Patch Name: fix_disabling_bad_string_offsets
Revision: 1323016981
URL:
https://bugs.php.net/patch-display.php?bug=60362&patch=fix_disabling_bad_string_offsets&revision=1323016981
[2011-12-04 12:52:52] alan at akbkhome dot com
This is the test output after the changes:
- most of this makes sense - string offsets of strings are now invalid, and the
dereferencing of strings with numerical indexes is 'fixed' and a behaviour
change.
BEHAVIOR CHANGED: sub-key 'non_existent' is not set.
expected: sub-key 1 is set: string(1) "o"
---
good: sub-sub-key 'sub_sub' is not set.
BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) "o"
---
BEHAVIOR CHANGED: sub-key 'non_existent' is empty.
expected: sub-key 1 is NOT empty: string(1) "o"
---
good: sub-sub-key 'sub_sub' is empty.
BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) "o"
[2011-11-23 01:37:51] danielc at analysisandsolutions dot com
Description:
In an array, a sub-sub-key of an existing key is now returning a letter of the
value indexed by the main key. This is a regression in 5.4. PHP 5.3 still
operates as expected. I suspect this is related to the array dereferencing
changes.
Test script:
---
$arr = array('exists' => 'foo');
if (isset($arr['exists']['non_existent'])) {
echo "expected: sub-key 'non_existent' is set: ";
var_dump($arr['exists']['non_existent']);
} else {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is not set.\n";
}
if (isset($arr['exists'][1])) {
echo "expected: sub-key 1 is set: ";
var_dump($arr['exists'][1]);
} else {
echo "BEHAVIOR CHANGED: sub-key 1 is not set.\n";
}
echo "---\n";
if (isset($arr['exists']['non_existent']['sub_sub'])) {
echo "BEHAVIOR CHANGED: sub-key 'sub_sub' is set: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
} else {
echo "good: sub-sub-key 'sub_sub' is not set.\n";
}
if (isset($arr['exists'][1][0])) {
echo "BEHAVIOR CHANGED: sub-sub-key 0 is set: ";
var_dump($arr['exists'][1][0]);
} else {
echo "good: sub-sub-key 0 is not set.\n";
}
echo "---\n";
if (empty($arr['exists']['non_existent'])) {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is empty.\n";
} else {
echo "expected: sub-key 'non_existent' is not empty: ";
var_dump($arr['exists']['non_existent']);
}
if (empty($arr['exists'][1])) {
echo "BEHAVIOR CHANGED: sub-key 1 is empty.\n";
} else {
echo "expected: sub-key 1 is NOT empty: ";
var_dump($arr['exists'][1]);
}
echo "---\n";
if (empty($arr['exists']['non_existent']['sub_sub'])) {
echo "good: sub-sub-key 'sub_sub' is empty.\n";
} else {
echo "BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
}
if (empty($arr['exists'][1][0])) {
echo "good: sub-sub-key 0 is empty.\n";
} else {
echo "BEHAVIOR CHANGED: sub-sub-key 0 is not empty: ";
var_dump($arr['exists'][1][0]);
}
Expected result:
expected: sub-key 'non_existent' is set: string(1) "f"
expected: sub-key 1 is set: string(1) "o"
---
good: sub-sub-key 'sub_sub' is not set.
good: sub-sub-key 0 is not set.
---
expected: sub-key 'non_existent' is not empty: string(1) "f"
expected: sub-key 1 is NOT empty: string(1) "o"
---
good: sub-sub-key 'sub_sub' is empty.
good: sub-sub-key 0 is empty.
Actual result:
--
expected: sub-key 'non_existent' is set: string(1) "f"
expected: sub-key 1 is set: string(1) "o"
---
BEHAVIOR CHANGED: sub-key 'sub_sub' is set: string(1) "f"
BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) "o"
---
expected: sub-key 'non_existent' is not empty: string(1) "f"
expected: sub-key 1 is NOT empty: string(1) "o"
---
BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: string(1) "f"
BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) "o"
--
Edit this bug report at https://bugs.
Bug #60362 [PATCH]: non-existent sub-sub keys should not have values
Edit report at https://bugs.php.net/bug.php?id=60362&edit=1
ID: 60362
Patch added by: larue...@php.net
Reported by:danielc at analysisandsolutions dot com
Summary:non-existent sub-sub keys should not have values
Status: Open
Type: Bug
Package:Arrays related
Operating System: linux
PHP Version:5.4SVN-2011-11-23 (SVN)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: fix_disabling_bad_string_offsets
Revision: 1323016981
URL:
https://bugs.php.net/patch-display.php?bug=60362&patch=fix_disabling_bad_string_offsets&revision=1323016981
Previous Comments:
[2011-12-04 12:52:52] alan at akbkhome dot com
This is the test output after the changes:
- most of this makes sense - string offsets of strings are now invalid, and the
dereferencing of strings with numerical indexes is 'fixed' and a behaviour
change.
BEHAVIOR CHANGED: sub-key 'non_existent' is not set.
expected: sub-key 1 is set: string(1) "o"
---
good: sub-sub-key 'sub_sub' is not set.
BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) "o"
---
BEHAVIOR CHANGED: sub-key 'non_existent' is empty.
expected: sub-key 1 is NOT empty: string(1) "o"
---
good: sub-sub-key 'sub_sub' is empty.
BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) "o"
[2011-11-23 01:37:51] danielc at analysisandsolutions dot com
Description:
In an array, a sub-sub-key of an existing key is now returning a letter of the
value indexed by the main key. This is a regression in 5.4. PHP 5.3 still
operates as expected. I suspect this is related to the array dereferencing
changes.
Test script:
---
$arr = array('exists' => 'foo');
if (isset($arr['exists']['non_existent'])) {
echo "expected: sub-key 'non_existent' is set: ";
var_dump($arr['exists']['non_existent']);
} else {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is not set.\n";
}
if (isset($arr['exists'][1])) {
echo "expected: sub-key 1 is set: ";
var_dump($arr['exists'][1]);
} else {
echo "BEHAVIOR CHANGED: sub-key 1 is not set.\n";
}
echo "---\n";
if (isset($arr['exists']['non_existent']['sub_sub'])) {
echo "BEHAVIOR CHANGED: sub-key 'sub_sub' is set: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
} else {
echo "good: sub-sub-key 'sub_sub' is not set.\n";
}
if (isset($arr['exists'][1][0])) {
echo "BEHAVIOR CHANGED: sub-sub-key 0 is set: ";
var_dump($arr['exists'][1][0]);
} else {
echo "good: sub-sub-key 0 is not set.\n";
}
echo "---\n";
if (empty($arr['exists']['non_existent'])) {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is empty.\n";
} else {
echo "expected: sub-key 'non_existent' is not empty: ";
var_dump($arr['exists']['non_existent']);
}
if (empty($arr['exists'][1])) {
echo "BEHAVIOR CHANGED: sub-key 1 is empty.\n";
} else {
echo "expected: sub-key 1 is NOT empty: ";
var_dump($arr['exists'][1]);
}
echo "---\n";
if (empty($arr['exists']['non_existent']['sub_sub'])) {
echo "good: sub-sub-key 'sub_sub' is empty.\n";
} else {
echo "BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
}
if (empty($arr['exists'][1][0])) {
echo "good: sub-sub-key 0 is empty.\n";
} else {
echo "BEHAVIOR CHANGED: sub-sub-key 0 is not empty: ";
var_dump($arr['exists'][1][0]);
}
Expected result:
expected: sub-key 'non_existent' is set: string(1) "f"
expected: sub-key 1 is set: string(1) "o"
---
good: sub-sub-key 'sub_sub' is not set.
good: sub-sub-key 0 is not set.
---
expected: sub-key 'non_existent' is not empty: string(1) "f"
expected: sub-key 1 is NOT empty: string(1) "o"
---
good: sub-sub-key 'sub_sub' is empty.
good: sub-sub-key 0 is empty.
Actual result:
--
expected: sub-key 'non_existent' is set: string(1) "f"
expected: sub-key 1 is set: string(1) "o"
---
BEHAVIOR CHANGED: sub-key 'sub_sub' is set: string(1) "f"
BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) "o"
---
expected: sub-key 'non_existent' is not empty: string(1) "f"
expected: sub-key 1 is NOT empty: string(1) "o"
---
BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: string(1) "f"
BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) "o"
--
Edit this bug report at https://bugs.php.net/bug.php?id=60362&edit=1
Bug #55478 [Opn->Csd]: FILTER_VALIDATE_EMAIL fails with valid addresses containing "--" twice
Edit report at https://bugs.php.net/bug.php?id=55478&edit=1
ID: 55478
Updated by: il...@php.net
Reported by:c...@php.net
Summary:FILTER_VALIDATE_EMAIL fails with valid addresses
containing "--" twice
-Status: Open
+Status: Closed
Type: Bug
Package:Filter related
Operating System: any
PHP Version:5.4.0alpha3
-Assigned To:
+Assigned To:iliaa
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-12-04 14:52:23] il...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=320369
Log: Fixed Bug #55478 (FILTER_VALIDATE_EMAIL fails with internationalized
domain name addresses containing >1 -).
[2011-08-22 17:00:16] c...@php.net
Description:
The FILTER_VALIDATE_EMAIL check fails with valid adresses that contain "--"
twice because they have e.g. a German Umlaut ("ä") after a dash ("-").
The following examples can be verified using the converter tool on the DeNIC
page at
http://www.denic.de/domains/internationalized-domain-names/idn-konvertierung.html
IDN: example-ä.de
ACE-String: xn--example--7za.de
Test script:
---
--TEST--
Bug #X (FILTER_VALIDATE_EMAIL fails with valid addresses containing "--"
twice)
--FILE--
--EXPECTF--
%unicode|string%(21) "t...@xn--example--7za.de"
Expected result:
"t...@xn--example--7za.de"
Actual result:
--
bool(false)
$ TEST_PHP_EXECUTABLE=/home/chammers/workspace/php-src-5.4/sX.phpt /php
./run-tests.php ext/filter/tests/bugX
=
PHP : /home/chammers/workspace/php-src-5.4/sapi/cli/php
PHP_SAPI: cli
PHP_VERSION : 5.4.0beta1-dev
ZEND_VERSION: 2.4.0
PHP_OS : Linux - Linux sys-251 2.6.38-bpo.2-686 #1 SMP Tue Jun 14 11:43:18
UTC 2011 i686
INI actual : /home/chammers/workspace/php5/php5-5.3.3
More .INIs :
CWD : /home/chammers/workspace/php5/php5-5.3.3
Extra dirs :
VALGRIND: Not used
=
Running selected tests.
FAIL Bug #X (FILTER_VALIDATE_EMAIL fails with valid addresses containing
"--" twice) [ext/filter/tests/bugX.phpt]
--
Edit this bug report at https://bugs.php.net/bug.php?id=55478&edit=1
Bug #55866 [Opn->Bgs]: PHP segfaults if IMAP server returns "\r\n00000005 NO FETCH failed..
Edit report at https://bugs.php.net/bug.php?id=55866&edit=1
ID: 55866
Updated by: il...@php.net
Reported by:thevlad at gmail dot com
Summary:PHP segfaults if IMAP server returns "\r\n0005
NO FETCH failed..
-Status: Open
+Status: Bogus
Type: Bug
Package:IMAP related
Operating System: Linux, Oracle Linux Server relea
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
The crash is happening deep inside the c-client library and not PHP, this is a
not
a PHP bug.
Previous Comments:
[2011-11-18 14:13:01] thevlad at gmail dot com
The same error in PHP 5.3.8
[2011-11-18 14:11:19] thevlad at gmail dot com
segfaults in PHP 5.3.8 as well.
[2011-10-07 17:08:54] thevlad at gmail dot com
Description:
PHP segfaults if IMAP server returns ""\r\n0005 NO FETCH failed: Internal
error\r\n"" randomly during communication.
[root@ ~]# rpm -qa|grep php
php-pear-Auth-SASL-1.0.4-1.el6.noarch
php-common-5.3.3-3.el6.x86_64
php-ldap-5.3.3-3.el6.x86_64
php-mysql-5.3.3-3.el6.x86_64
php-gd-5.3.3-3.el6.x86_64
php-pear-1.9.0-2.el6.noarch
php-pear-Mail-1.2.0-1.el6.noarch
php-cli-5.3.3-3.el6.x86_64
php-pdo-5.3.3-3.el6.x86_64
php-xml-5.3.3-3.el6.x86_64
php-pear-Net-Socket-1.0.10-1.el6.noarch
php-debuginfo-5.3.3-3.el6.x86_64
php-5.3.3-3.el6.x86_64
php-imap-5.3.3-3.el6.x86_64
php-pear-Net-SMTP-1.6.0-1.el6.noarch
(gdb) bt
#0 0x7fe6b51ac221 in tcp_host (stream=0x0) at tcp_unix.c:767
#1 0x7fe6b51e709c in imap_parse_header (stream=,
env=0x31594f0, hdr=0x7fff861b71c0,
stl=0x0) at imap4r1.c:4525
#2 0x7fe6b51e73e2 in imap_cache (stream=0x309eba0, msgno=1, seg=, stl=0x0,
text=0x7fff861b71c0) at imap4r1.c:5022
#3 0x7fe6b51ea01c in imap_parse_unsolicited (stream=0x309eba0,
reply=0x309ee08) at imap4r1.c:3835
#4 0x7fe6b51eabf3 in imap_reply (stream=0x309eba0, tag=0x7fff861b7870
"0005") at imap4r1.c:3560
#5 0x7fe6b51eade3 in imap_sout (stream=0x309eba0, tag=0x7fff861b7870
"0005", base=0x309eeb0 "",
s=0x7fff861b7468) at imap4r1.c:3519
#6 0x7fe6b51ec0d5 in imap_send (stream=0x309eba0, cmd=0x7fe6b5287039
"FETCH", args=0x7fff861b7900)
at imap4r1.c:3129
#7 0x7fe6b51f0987 in imap_msgdata (stream=0x309eba0, msgno=1, section=
, first=0,
last=0, lines=, flags=) at
imap4r1.c:1845
#8 0x7fe6b51c52df in mail_fetch_header (stream=0x309eba0, msgno=1,
section=0x0, lines=0x0, len=0x0,
flags=2) at mail.c:1748
#9 0x7fe6b54aa963 in zif_imap_fetchheader (ht=2, return_value=0x30550f0,
return_value_ptr=, this_ptr=,
return_value_used=) at /usr/src/debug/php-
5.3.3/ext/imap/php_imap.c:3140
#10 0x005f5e58 in zend_do_fcall_common_helper_SPEC (execute_data=)
at /usr/src/debug/php-5.3.3/Zend/zend_vm_execute.h:316
#11 0x005cd180 in execute (op_array=0x2307380) at /usr/src/debug/php-
5.3.3/Zend/zend_vm_execute.h:107
#12 0x005a787d in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/src/debug/php-5.3.3/Zend/zend.c:1194
---Type to continue, or q to quit---
#13 0x00555b48 in php_execute_script (primary_file=0x7fff861baae0)
at /usr/src/debug/php-5.3.3/main/main.c:2260
#14 0x006315ee in main (argc=6, argv=0x7fff861bace8)
at /usr/src/debug/php-5.3.3/sapi/cli/php_cli.c:1192
#0 0x7fe6b51ac221 in tcp_host (stream=0x0) at tcp_unix.c:767
No locals.
#1 0x7fe6b51e709c in imap_parse_header (stream=,
env=0x31594f0, hdr=0x7fff861b71c0,
stl=0x0) at imap4r1.c:4525
nenv = 0x7fff861b71c0
#2 0x7fe6b51e73e2 in imap_cache (stream=0x309eba0, msgno=1, seg=, stl=0x0,
text=0x7fff861b71c0) at imap4r1.c:5022
...
ret = 0x3159528
stc =
elt = 0x31594b0
#3 0x7fe6b51ea01c in imap_parse_unsolicited (stream=0x309eba0,
reply=0x309ee08) at imap4r1.c:3835
stl = 0x0
---Type to continue, or q to quit---
text = {data = 0x314bff0 "\r\n0005 NO FETCH failed: Internal
error\r\n", size = 1655}
Actual result:
--
(gdb) bt
#0 0x7fe6b51ac221 in tcp_host (stream=0x0) at tcp_unix.c:767
#1 0x7fe6b51e709c in imap_parse_header (stream=,
env=0x31594f0, hdr=0x7fff861b71c0,
stl=0x0) at imap4r1.c:
Bug #60362 [Com]: non-existent sub-sub keys should not have values
Edit report at https://bugs.php.net/bug.php?id=60362&edit=1
ID: 60362
Comment by: alan at akbkhome dot com
Reported by:danielc at analysisandsolutions dot com
Summary:non-existent sub-sub keys should not have values
Status: Open
Type: Bug
Package:Arrays related
Operating System: linux
PHP Version:5.4SVN-2011-11-23 (SVN)
Block user comment: N
Private report: N
New Comment:
This is the test output after the changes:
- most of this makes sense - string offsets of strings are now invalid, and the
dereferencing of strings with numerical indexes is 'fixed' and a behaviour
change.
BEHAVIOR CHANGED: sub-key 'non_existent' is not set.
expected: sub-key 1 is set: string(1) "o"
---
good: sub-sub-key 'sub_sub' is not set.
BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) "o"
---
BEHAVIOR CHANGED: sub-key 'non_existent' is empty.
expected: sub-key 1 is NOT empty: string(1) "o"
---
good: sub-sub-key 'sub_sub' is empty.
BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) "o"
Previous Comments:
[2011-11-23 01:37:51] danielc at analysisandsolutions dot com
Description:
In an array, a sub-sub-key of an existing key is now returning a letter of the
value indexed by the main key. This is a regression in 5.4. PHP 5.3 still
operates as expected. I suspect this is related to the array dereferencing
changes.
Test script:
---
$arr = array('exists' => 'foo');
if (isset($arr['exists']['non_existent'])) {
echo "expected: sub-key 'non_existent' is set: ";
var_dump($arr['exists']['non_existent']);
} else {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is not set.\n";
}
if (isset($arr['exists'][1])) {
echo "expected: sub-key 1 is set: ";
var_dump($arr['exists'][1]);
} else {
echo "BEHAVIOR CHANGED: sub-key 1 is not set.\n";
}
echo "---\n";
if (isset($arr['exists']['non_existent']['sub_sub'])) {
echo "BEHAVIOR CHANGED: sub-key 'sub_sub' is set: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
} else {
echo "good: sub-sub-key 'sub_sub' is not set.\n";
}
if (isset($arr['exists'][1][0])) {
echo "BEHAVIOR CHANGED: sub-sub-key 0 is set: ";
var_dump($arr['exists'][1][0]);
} else {
echo "good: sub-sub-key 0 is not set.\n";
}
echo "---\n";
if (empty($arr['exists']['non_existent'])) {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is empty.\n";
} else {
echo "expected: sub-key 'non_existent' is not empty: ";
var_dump($arr['exists']['non_existent']);
}
if (empty($arr['exists'][1])) {
echo "BEHAVIOR CHANGED: sub-key 1 is empty.\n";
} else {
echo "expected: sub-key 1 is NOT empty: ";
var_dump($arr['exists'][1]);
}
echo "---\n";
if (empty($arr['exists']['non_existent']['sub_sub'])) {
echo "good: sub-sub-key 'sub_sub' is empty.\n";
} else {
echo "BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
}
if (empty($arr['exists'][1][0])) {
echo "good: sub-sub-key 0 is empty.\n";
} else {
echo "BEHAVIOR CHANGED: sub-sub-key 0 is not empty: ";
var_dump($arr['exists'][1][0]);
}
Expected result:
expected: sub-key 'non_existent' is set: string(1) "f"
expected: sub-key 1 is set: string(1) "o"
---
good: sub-sub-key 'sub_sub' is not set.
good: sub-sub-key 0 is not set.
---
expected: sub-key 'non_existent' is not empty: string(1) "f"
expected: sub-key 1 is NOT empty: string(1) "o"
---
good: sub-sub-key 'sub_sub' is empty.
good: sub-sub-key 0 is empty.
Actual result:
--
expected: sub-key 'non_existent' is set: string(1) "f"
expected: sub-key 1 is set: string(1) "o"
---
BEHAVIOR CHANGED: sub-key 'sub_sub' is set: string(1) "f"
BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) "o"
---
expected: sub-key 'non_existent' is not empty: string(1) "f"
expected: sub-key 1 is NOT empty: string(1) "o"
---
BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: string(1) "f"
BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) "o"
--
Edit this bug report at https://bugs.php.net/bug.php?id=60362&edit=1
Bug #55103 [Com]: Interfaces avoids Classes to exist
Edit report at https://bugs.php.net/bug.php?id=55103&edit=1
ID: 55103
Comment by: clicky at erebot dot net
Reported by:imaggens at gmail dot com
Summary:Interfaces avoids Classes to exist
Status: Open
Type: Bug
Package:Class/Object related
Operating System: Windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
PHP expects the parent classes/interfaces to have been defined before the class
that extends/implements them.
If I change the order of the lines from code sample #2 (eIUJWp56) to read:
getMessage();
}
}
class First extends Zero {}
}
?>
Then PHP 5.3.3, PHP 5.3.8 & PHP 5.4.0RC2 happily accept the file (no error).
Previous Comments:
[2011-08-24 22:27:45] imaggens at gmail dot com
Sorry, I don't know if it's allowed to do that, but is there any position about
this bug report?
[2011-07-02 10:11:05] imaggens at gmail dot com
Sorry about the code, it was my mistake.
The correct code for Code Sample #2 is: http://codepad.org/eIUJWp56
And as requested, the code of other file:
getMessage();
}
?>
I tried without the try...catch() and with it and, in both cases the error
remains.
[2011-07-01 16:26:46] f...@php.net
It seems to me your 2 code samples are identical, just one has output attached.
Where's the interface?
Please provide a *complete* sample, i.e. if your including one file make clear
what's in both files, the one having a call to "require" and the one being
required
[2011-07-01 10:07:08] imaggens at gmail dot com
Description:
First at all, one consideration about one of the informations provided in this
form is the PHP version. I'm not using 5.3.6. I'm using 5.3.3, which is not
listed. I f I chose "earlier", the form won't submit.
I can be wrong, but I think this bug is not fixed in newer versions, because
it's not a very common use.
The whole thing is, when interfaces and classes are in the same namespace AND
in same file, the 'implements' breaks the execution of the 'extends'. See Code
#1
As expected I can see "Message from Second Class", without quotes.
But if I add a interface (see Code #2) I get a Fatal Error: "Class 'Test\Zero'
not found", when it could be expected the same result as before.
But why this is important, if the best practices are to develop by following an
organized structure, with each class/interface in its own file?
The thing is, when DEVELOPING, this kind of organization is very useful, but if
the code produced during development stage is a little library, if all the
classes and interfaces are coded in one single file, only one call to
require_once is needed, and the code execution is three times faster than when
using an autoloader resource.
Note about CodePad's codes: I'd only saved the lines of code in this site, they
don't work from it, due PHP versions. But all the tests I made was in machine
with the configurations posted.
Test script:
---
[ Code #1 ]
http://codepad.org/pDOAiqBa
[ Code #2 ]
http://codepad.org/a42WgIT3
Expected result:
As said in Bug's Description, "Message from Second Class", witout quotes.
Actual result:
--
With the first code, I can see the expected result.
With the second code, as I said, I see a Fatal Error. If the stack traces
helps, here is it:
Fatal error: Class 'Test\Test\Zero' not found in C:\root\Test\Library.php on
line 5
Call Stack
# TimeMemory FunctionLocation
1 0.0004 326896 {main}( ) ..\index.php:0
2 0.0018 334024 require_once( 'C:\root\Test\Framework.php' )
..\index.php:3
Dump $_GET
Dump $_POST
--
Edit this bug report at https://bugs.php.net/bug.php?id=55103&edit=1
Req #45601 [Com]: Extending interfaces
Edit report at https://bugs.php.net/bug.php?id=45601&edit=1
ID: 45601
Comment by: clicky at erebot dot net
Reported by:david at grudl dot com
Summary:Extending interfaces
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: irrelevant
PHP Version:5.3CVS-2008-07-23 (snap)
Block user comment: N
Private report: N
New Comment:
This issue and a few others dealing with interfaces have been solved in PHP
5.4RC2 & 5.3.9RC2.
Previous Comments:
[2011-03-23 00:11:36] clicky at erebot dot net
See also bug #46705 for other suggestions on how to improve the way interfaces
currently work in PHP.
[2008-07-23 11:33:10] david at grudl dot com
p.s. is really the error message formulation "(previously declared abstract in
IHuman)" correct?
[2008-07-23 11:30:28] david at grudl dot com
Description:
I think this fatal error is needless.
Interface implementors can append optional parameter:
interface IAnimal
{
function speak();
}
class Dog implements IAnimal
{
function speak($optional = NULL)
{
echo 'Bark!';
}
}
class Labrador extends Dog
{
function speak($optional = NULL, $anotherOptinal = NULL)
{
...
}
}
That's correct behaviour. But the same behaviour is unallowed for interface
extenders.
Reproduce code:
---
interface IAnimal
{
function speak();
}
interface IHuman extends IAnimal
{
function speak($language = NULL);
}
Expected result:
no error
Actual result:
--
Fatal error: Can't inherit abstract function IAnimal::speak() (previously
declared abstract in IHuman)
--
Edit this bug report at https://bugs.php.net/bug.php?id=45601&edit=1
