[PHP-BUG] Bug #64318 [NEW]: emake error::undefined reference to `pcre_info'
From: amitsett at gmail dot com Operating system: 2.6.35-gentoo-r5 PHP version: Irrelevant Package: Compile Failure Bug Type: Bug Bug description:emake error::undefined reference to `pcre_info' Description: emerge -av =php=5.2.17 fails with the following error: /bin/sh /var/tmp/portage/dev-lang/php-5.2.17/work/sapis-build/cli/libtool --silent --preserve- dup-deps --mode=link i686-pc-linux-gnu-gcc -export-dynamic -I/usr/include -O2 - march=native - mfpmath=sse -pipe -fomit-frame-pointer -msse2 -D_GNU_SOURCE - L/usr/lib/postgresql-8.1/lib - Wl,-O1 -Wl,--as-needed -R /usr/lib/postgresql-8.1/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/libxml/libxml.lo ext/openssl/openssl.lo ext/openssl/xp_ssl.lo ext/pcre/php_pcre.lo ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/zlib/zlib_filter.lo ext/bcmath/bcmath.lo ext/bcmath/libbcmath/src/add.lo ext/bcmath/libbcmath/src/div.lo ext/bcmath/libbcmath/src/init.lo ext/bcmath/libbcmath/src/neg.lo ext/bcmath/libbcmath/src/outofmem.lo ext/bcmath/libbcmath/src/raisemod.lo ext/bcmath/libbcmath/src/rt.lo ext/bcmath/libbcmath/src/sub.lo ext/bcmath/libbcmath/src/compare.lo ext/bcmath/libbcmath/src/divmod.lo ext/bcmath/libbcmath/src/int2num.lo ext/bcmath/libbcmath/src/num2long.lo ext/bcmath/libbcmath/src/output.lo ext/bcmath/libbcmath/src/recmul.lo ext/bcmath/libbcmath/src/sqrt.lo ext/bcmath/libbcmath/src/zero.lo ext/bcmath/libbcmath/src/debug.lo ext/bcmath/libbcmath/src/doaddsub.lo ext/bcmath/libbcmath/src/nearzero.lo ext/bcmath/libbcmath/src/num2str.lo ext/bcmath/libbcmath/src/raise.lo ext/bcmath/libbcmath/src/rmzero.lo ext/bcmath/libbcmath/src/str2num.lo ext/bz2/bz2.lo ext/bz2/bz2_filter.lo ext/ctype/ctype.lo ext/curl/interface.lo ext/curl/multi.lo ext/curl/streams.lo ext/dba/dba.lo ext/dba/dba_cdb.lo ext/dba/dba_dbm.lo ext/dba/dba_gdbm.lo ext/dba/dba_ndbm.lo ext/dba/dba_db1.lo ext/dba/dba_db2.lo ext/dba/dba_db3.lo ext/dba/dba_db4.lo ext/dba/dba_flatfile.lo ext/dba/dba_inifile.lo ext/dba/dba_qdbm.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/filter/filter.lo ext/filter/sanitizing_filters.lo ext/filter/logical_filters.lo ext/filter/callback_filter.lo ext/gd/gd.lo ext/gd/gdttf.lo ext/gd/libgd/gd.lo ext/gd/libgd/gd_gd.lo ext/gd/libgd/gd_gd2.lo ext/gd/libgd/gd_io.lo ext/gd/libgd/gd_io_dp.lo ext/gd/libgd/gd_io_file.lo ext/gd/libgd/gd_ss.lo ext/gd/libgd/gd_io_ss.lo ext/gd/libgd/gd_png.lo ext/gd/libgd/gd_jpeg.lo ext/gd/libgd/gdxpm.lo ext/gd/libgd/gdfontt.lo ext/gd/libgd/gdfonts.lo ext/gd/libgd/gdfontmb.lo ext/gd/libgd/gdfontl.lo ext/gd/libgd/gdfontg.lo ext/gd/libgd/gdtables.lo ext/gd/libgd/gdft.lo ext/gd/libgd/gdcache.lo ext/gd/libgd/gdkanji.lo ext/gd/libgd/wbmp.lo ext/gd/libgd/gd_wbmp.lo ext/gd/libgd/gdhelpers.lo ext/gd/libgd/gd_topal.lo ext/gd/libgd/gd_gif_in.lo ext/gd/libgd/xbm.lo ext/gd/libgd/gd_gif_out.lo ext/gd/libgd/gd_security.lo ext/gettext/gettext.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/iconv/iconv.lo ext/json/json.lo ext/json/utf8_to_utf16.lo ext/json/utf8_decode.lo ext/json/JSON_parser.lo ext/mbstring/oniguruma/regcomp.lo ext/mbstring/oniguruma/regerror.lo ext/mbstring/oniguruma/regexec.lo ext/mbstring/oniguruma/reggnu.lo ext/mbstring/oniguruma/regparse.lo ext/mbstring/oniguruma/regenc.lo ext/mbstring/oniguruma/regext.lo ext/mbstring/oniguruma/regsyntax.lo ext/mbstring/oniguruma/regtrav.lo ext/mbstring/oniguruma/regversion.lo ext/mbstring/oniguruma/st.lo ext/mbstring/oniguruma/enc/unicode.lo ext/mbstring/oniguruma/enc/ascii.lo ext/mbstring/oniguruma/enc/utf8.lo ext/mbstring/oniguruma/enc/euc_jp.lo ext/mbstring/oniguruma/enc/euc_tw.lo ext/mbstring/oniguruma/enc/euc_kr.lo ext/mbstring/oniguruma/enc/sjis.lo ext/mbstring/oniguruma/enc/iso8859_1.lo ext/mbstring/oniguruma/enc/iso8859_2.lo ext/mbstring/oniguruma/enc/iso8859_3.lo ext/mbstring/oniguruma/enc/iso8859_4.lo
Bug #27777 [Com]: basic authentication broken
Edit report at https://bugs.php.net/bug.php?id=2edit=1 ID: 2 Comment by: stephan dot schulze at kapthon dot com Reported by:mikx at mikx dot de Summary:basic authentication broken Status: No Feedback Type: Bug Package:SOAP related Operating System: Windows XP Pro PHP Version:5.0.0RC1 Block user comment: N Private report: N New Comment: This problem still exists in PHP 5.3.20 Previous Comments: [2012-06-13 09:00:19] oliver at mojofuel dot com Still exists in PHP 5.3.13 [2011-10-20 00:37:35] dewes at pop dot com dot br The problem still in PHP Version 5.3.5. [2010-11-15 16:56:31] oliver at teqneers dot de I have the same problem in PHP 5.3.3. It is not possible to fetch a HTTP basic/digest authentication protected WSDL. [2010-01-29 21:38:40] eric dot caron at gmail dot com Still having this problem as of PHP 5.3.2-dev on my Linux boxes. PHP 5.3.1 on my Windows box did not have this problem. [2009-05-07 13:32:47] Christian dot Reingruber at gmail dot com still a problem in 5.2.8 i guess... any ideas? 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=2 -- Edit this bug report at https://bugs.php.net/bug.php?id=2edit=1
Req #13756 [Com]: exponential ** operator
Edit report at https://bugs.php.net/bug.php?id=13756edit=1 ID: 13756 Comment by: tom at r dot je Reported by:san...@php.net Summary:exponential ** operator Status: Closed Type: Feature/Change Request Package:Feature/Change Request Operating System: n/a PHP Version:4.0.6 Block user comment: N Private report: N New Comment: Indeed! Seems very despotic just to say No. Deal with it with no further discussion or explanation why. Previous Comments: [2012-07-08 23:31:23] hello at wesalvaro dot com le why not? [2002-04-27 16:17:03] j...@php.net not going to happen. just suck it up and use pow(). [2001-10-19 18:51:47] jer...@php.net I proposed that earlier (along with ^^) [ZendEnginge ML, june 27th july 3rd]. Anyway, I think it should be added, there is simply no power operator now, and pow() is both a bit bugly and overloaded (both ^^ and ** at the same time). [2001-10-19 11:24:28] hholz...@php.net ** is Pascal, not C [2001-10-19 10:36:03] san...@php.net It would be nice to have an exponential operator. ** would be a logical choice, just like in C. Example: echo 2**3; // prints 8 I know we have pow(), but an operator for this would be nice... -- Edit this bug report at https://bugs.php.net/bug.php?id=13756edit=1
[PHP-BUG] Bug #64319 [NEW]: max_input_vars warning unknown file
From: david at davidsteinsland dot net Operating system: CentOS PHP version: 5.4.12 Package: *General Issues Bug Type: Bug Bug description:max_input_vars warning unknown file Description: When PHP raises a warning about max_input_vars being exceeded, it would be very helpful to see which file actually caused the error. The current error message just says Unknown on line 0. Expected result: Script file name Actual result: -- Unknown file -- Edit bug report at https://bugs.php.net/bug.php?id=64319edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64319r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64319r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64319r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64319r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64319r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64319r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64319r=needscript Try newer version: https://bugs.php.net/fix.php?id=64319r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64319r=support Expected behavior: https://bugs.php.net/fix.php?id=64319r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64319r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64319r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64319r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64319r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64319r=dst IIS Stability: https://bugs.php.net/fix.php?id=64319r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64319r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64319r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64319r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64319r=mysqlcfg
Bug #44383 [Com]: PHP DateTime not converted to xsd:datetime
Edit report at https://bugs.php.net/bug.php?id=44383edit=1 ID: 44383 Comment by: stefan dot giesecke at avl-investmentfonds dot de Reported by:kevin dot craft at gmail dot com Summary:PHP DateTime not converted to xsd:datetime Status: No Feedback Type: Bug Package:SOAP related Operating System: * PHP Version:5.*, 6 (2009-08-07 Assigned To:mj Block user comment: N Private report: N New Comment: Please fix this issue, prefer the example from thomas dot lallement at 9online dot fr. Optional or not optional I don't care. Previous Comments: [2013-02-18 00:33:54] php-bugs at lists dot php dot net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2013-01-21 18:37:58] thomas dot lallement at 9online dot fr For me, when you call $client-getCurrentDate(), the expected result would be to have a PHP DateTime object rather than a string. So the expected result should be: DateTime Object ( [date] = 2008-03-06 00:00:00 [timezone_type] = x [timezone] = /x ) What do you think about this? At least an option could be provide throught the SoapClient to permit this behavior. [2012-12-24 07:29:52] m...@php.net David, I applied your patch to 5.6.0-dev but all the new tests are failing due to empty responses from SoapServer. Do you have some cycles to look into this? [2012-05-03 10:33:48] andyidol at gmail dot com Please fix this! I beg you ) [2012-01-25 19:44:20] frozenf...@php.net I've encountered this issue today, and it would be really wonderful to have this patch applied. 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=44383 -- Edit this bug report at https://bugs.php.net/bug.php?id=44383edit=1
[PHP-BUG] Req #64320 [NEW]: Proposal: deprecate the leading 0 means octal behaviour
From: php at richardneill dot org Operating system: All PHP version: 5.4.12 Package: Math related Bug Type: Feature/Change Request Bug description:Proposal: deprecate the leading 0 means octal behaviour Description: PHP assumes that a string with a leading zero should be interpreted as octal. In my experience, this is almost never useful, desirable, or intentional, however, it is a frequent trap for the beginner (or more experienced programmer), especially when parsing user-submitted data. The only reason for this behaviour seems to be historical, and compatibility with strtol(). When non-programmer humans write numbers with leading zeros, they don't usually mean base 8. My proposal is: 1. Introduce a new string format, 0o (letter o), to explicitly mean this is an octal number. This is similar to the recent introduction of 0b for binary numbers. [This part should be simple to do, and would also make the intentional use of octal notation explicit, increasing code-readability] 2. Add an option to raise E_NOTICE any time a number is implicitly interpreted as octal (for example $x = 0100). 3. In a few years time, (PHP 7?), it may finally be possible to change the default behaviour. Test script: --- Here's an illustration of a naive program that has data-dependent bugs that are really hard to track down. $mass_kg = 0.314 //user-submitted data, known to begin 0. $mass_g = substr ($mass_kg, 2); Yes, this is a silly thing to write. But it's a nasty trap for the unwary. The above example does what is expected, and might pass many tests. But if the user subsequently enters $mass_kg = 0.031, this will turn into 25 grams, not 31 grams. As a result, we have created a very subtle and hard to find bug. -- Edit bug report at https://bugs.php.net/bug.php?id=64320edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64320r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64320r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64320r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64320r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64320r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64320r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64320r=needscript Try newer version: https://bugs.php.net/fix.php?id=64320r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64320r=support Expected behavior: https://bugs.php.net/fix.php?id=64320r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64320r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64320r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64320r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64320r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64320r=dst IIS Stability: https://bugs.php.net/fix.php?id=64320r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64320r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64320r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64320r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64320r=mysqlcfg
[PHP-BUG] Bug #64322 [NEW]: $_ENV{PATH} does not work
From: porton at narod dot ru
Operating system: Debian Linux
PHP version: 5.5Git-2013-02-28 (Git)
Package: *General Issues
Bug Type: Bug
Bug description:$_ENV{PATH} does not work
Description:
With Bash:
$ php -r 'echo $_ENV{PATH}, \n;'
PHP Notice: Undefined index: PATH in Command line code on line 1
The variable PATH is of course defined in my Bash.
Version info:
Debian Linux Wheezy
$ php --version
PHP 5.4.4-13 (cli) (built: Feb 19 2013 12:42:38)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
Test script:
---
php -r 'echo $_ENV{PATH}, \n;'
--
Edit bug report at https://bugs.php.net/bug.php?id=64322edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64322r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64322r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64322r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64322r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64322r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64322r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64322r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64322r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64322r=support
Expected behavior: https://bugs.php.net/fix.php?id=64322r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64322r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64322r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64322r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64322r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64322r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64322r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64322r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64322r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64322r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64322r=mysqlcfg
[PHP-BUG] Req #64323 [NEW]: Float inconsistency between echo/var_dump and tests
From: guaycuru at gmail dot com Operating system: Any PHP version: 5.4.12 Package: Scripting Engine problem Bug Type: Feature/Change Request Bug description:Float inconsistency between echo/var_dump and tests Description: So, I know that due to the way computers store float numbers, we end up with some oddities. This BUG is NOT about that. Instead, I found some inconsistencies on how PHP handle that, and it's easy to think of cases that those inconsistencies would end up causing lots of wasted hours debugging. Please see test script, it should be pretty self explanatory. My change request is that, since float / echo deal with that inconsistency (rounding 0.3000444089209850062616169452667236328125 to 0.3), so should control flow functions like IF, WHILE, etc... Tested on PHP 5.3.22 and PHP 5.4.12 Test script: --- ?php $a = 0.1; $b = 0.2; var_dump($a + $b); if($a + $b = 0.3) echo All is right in the universe!; else echo Something is wrong here!; ? Expected result: float(0.3) All is right in the universe! Also, this result is acceptable: float(0.3000444089209850062616169452667236328125) Something is wrong here! Actual result: -- float(0.3) Something is wrong here! -- Edit bug report at https://bugs.php.net/bug.php?id=64323edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64323r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64323r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64323r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64323r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64323r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64323r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64323r=needscript Try newer version: https://bugs.php.net/fix.php?id=64323r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64323r=support Expected behavior: https://bugs.php.net/fix.php?id=64323r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64323r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64323r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64323r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64323r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64323r=dst IIS Stability: https://bugs.php.net/fix.php?id=64323r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64323r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64323r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64323r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64323r=mysqlcfg
[PHP-BUG] Bug #64324 [NEW]: Why 0 == 'BOOK' ?
From: dosergio at ig dot com dot br
Operating system: all
PHP version: Irrelevant
Package: *General Issues
Bug Type: Bug
Bug description:Why 0 == 'BOOK' ?
Description:
If the comparison where
0 == '' that would make sense.
But I am chanlenging some PHP expert to convince us that the result 1 is
right for the comparison 0 == 'ANY STRING'
Test script:
---
if( 0 == 'TEST'){
echo PHP thinks 0 is equal 'TEST';
}
Expected result:
0 is not similar to a string that is NOT empty.
this comparison should return FALSE.
Actual result:
--
it returns 1
--
Edit bug report at https://bugs.php.net/bug.php?id=64324edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64324r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64324r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64324r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64324r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64324r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64324r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64324r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64324r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64324r=support
Expected behavior: https://bugs.php.net/fix.php?id=64324r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64324r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64324r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64324r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64324r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64324r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64324r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64324r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64324r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64324r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64324r=mysqlcfg
Bug #64324 [Opn]: Why 0 == 'BOOK' ?
Edit report at https://bugs.php.net/bug.php?id=64324edit=1
ID: 64324
User updated by:dosergio at ig dot com dot br
Reported by:dosergio at ig dot com dot br
Summary:Why 0 == 'BOOK' ?
Status: Open
Type: Bug
Package:*General Issues
Operating System: all
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
*If the comparison WERE
Previous Comments:
[2013-02-28 14:54:24] dosergio at ig dot com dot br
Description:
If the comparison where
0 == '' that would make sense.
But I am chanlenging some PHP expert to convince us that the result 1 is right
for the comparison 0 == 'ANY STRING'
Test script:
---
if( 0 == 'TEST'){
echo PHP thinks 0 is equal 'TEST';
}
Expected result:
0 is not similar to a string that is NOT empty.
this comparison should return FALSE.
Actual result:
--
it returns 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=64324edit=1
Req #64323 [Opn-Nab]: Float inconsistency between echo/var_dump and tests
Edit report at https://bugs.php.net/bug.php?id=64323edit=1
ID: 64323
Updated by: ras...@php.net
Reported by:guaycuru at gmail dot com
Summary:Float inconsistency between echo/var_dump and tests
-Status: Open
+Status: Not a bug
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: Any
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
You are getting the display precision confused with the internal representation
of a float. You can change the display precision with ini_set('precision',32);
If you do that your output becomes:
float(0.30004440892098500626)
Something is wrong here!
It is just at the default display precision you end up with 0.3 in your case,
but that has nothing to do with the internal representation of the float.
Previous Comments:
[2013-02-28 14:27:43] guaycuru at gmail dot com
Description:
So, I know that due to the way computers store float numbers, we end up with
some
oddities. This BUG is NOT about that. Instead, I found some inconsistencies on
how
PHP handle that, and it's easy to think of cases that those inconsistencies
would
end up causing lots of wasted hours debugging.
Please see test script, it should be pretty self explanatory.
My change request is that, since float / echo deal with that inconsistency
(rounding 0.3000444089209850062616169452667236328125 to 0.3), so
should control flow functions like IF, WHILE, etc...
Tested on PHP 5.3.22 and PHP 5.4.12
Test script:
---
?php
$a = 0.1;
$b = 0.2;
var_dump($a + $b);
if($a + $b = 0.3)
echo All is right in the universe!;
else
echo Something is wrong here!;
?
Expected result:
float(0.3)
All is right in the universe!
Also, this result is acceptable:
float(0.3000444089209850062616169452667236328125)
Something is wrong here!
Actual result:
--
float(0.3)
Something is wrong here!
--
Edit this bug report at https://bugs.php.net/bug.php?id=64323edit=1
Bug #64324 [Opn-Nab]: Why 0 == 'BOOK' ?
Edit report at https://bugs.php.net/bug.php?id=64324edit=1
ID: 64324
Updated by: ras...@php.net
Reported by:dosergio at ig dot com dot br
Summary:Why 0 == 'BOOK' ?
-Status: Open
+Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: all
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
You are doing a loose comparison between two different types. PHP has to pick a
type for it. In this case it does 0 == (int)'TEST' and casting 'TEST' to an int
is obviously going to give you 0. This is what you are going to want in most
cases. eg. 12 == 12 (with an extra space there). Chances are the 12 came
from user input since everything that comes from either the browser or your
backend database comes to you as strings, you are going to want that comparison
to work. If you cast both to strings instead they wouldn't.
If you don't want PHP to guess, use ===
Previous Comments:
[2013-02-28 14:55:44] dosergio at ig dot com dot br
*If the comparison WERE
[2013-02-28 14:54:24] dosergio at ig dot com dot br
Description:
If the comparison where
0 == '' that would make sense.
But I am chanlenging some PHP expert to convince us that the result 1 is right
for the comparison 0 == 'ANY STRING'
Test script:
---
if( 0 == 'TEST'){
echo PHP thinks 0 is equal 'TEST';
}
Expected result:
0 is not similar to a string that is NOT empty.
this comparison should return FALSE.
Actual result:
--
it returns 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=64324edit=1
Bug #64299 [Com]: Global variables not visible when using CLI
Edit report at https://bugs.php.net/bug.php?id=64299edit=1
ID: 64299
Comment by: anon at anon dot anon
Reported by:andrew dot mof at gmail dot com
Summary:Global variables not visible when using CLI
Status: Not a bug
Type: Bug
Package:Variables related
Operating System: Ubuntu 12.10
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
@pajoye: register_globals has nothing to do with this; what are you saying?
That said, the test script appears to work perfectly. How could it not?
Previous Comments:
[2013-02-26 04:16:17] paj...@php.net
In PHP 4.2.0, the 'register_globals' setting default changed to
'off'. See http://www.php.net/release_4_2_0.php for more info.
We are sorry about the inconvenience, but this change was a necessary
part of our efforts to make PHP scripting more secure and portable.
There is no bug here. Works just fine.
[2013-02-25 21:50:34] andrew dot mof at gmail dot com
Description:
99% sure this is a bug. This code works fine when apache runs it but when I run
it though CLI it doesnt see the variable.
That said, this work:
$GLOBALS['jobID'] = 123;
Test script:
---
#!/usr/bin/php
?php
// In my script this function is included in a seperate file
function addLine() {
global $jobID;
echo $jobID;
}
$jobID = 123;
addLine();
--
Edit this bug report at https://bugs.php.net/bug.php?id=64299edit=1
[PHP-BUG] Bug #64325 [NEW]: Issue in automatic $_POST array handling
From: php at sygmoral dot com
Operating system: Debian
PHP version: 5.4.12
Package: Arrays related
Bug Type: Bug
Bug description:Issue in automatic $_POST array handling
Description:
Php automatically puts POSTed name-value pairs with names ending in [] into
arrays. Very handy feature! However, I notice issues when more of those
square brackets are encountered.
If I send a name like `save[line[]]`, then `save` will be an array and the
first key in it will be `line[`, instead of `line[]`. It's not that I
expect a second level of arrays - just that it doesn't strangely remove
that last bracket.
So suppose we have the tiny php script below, and I send this with e.g.
jquery:
post_data = {'save[line[]]':'A line with text'}
Effectively, the raw POST data being sent is:
save%5Bline%5B%5D%5D=A+line+with+text
Test script:
---
print_r(
$_POST['save']
);
Expected result:
POST: Array
(
[line[]] = A line with text
)
Actual result:
--
POST: Array
(
[line[] = A line with text
)
--
Edit bug report at https://bugs.php.net/bug.php?id=64325edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64325r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64325r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64325r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64325r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64325r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64325r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64325r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64325r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64325r=support
Expected behavior: https://bugs.php.net/fix.php?id=64325r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64325r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64325r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64325r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64325r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64325r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64325r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64325r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64325r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64325r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64325r=mysqlcfg
[PHP-BUG] Bug #64326 [NEW]: Parse error on casting a bracket array to an object
From: f at worldhomes dot com Operating system: Mac PHP version: 5.4.12 Package: *General Issues Bug Type: Bug Bug description:Parse error on casting a bracket array to an object Description: This code does not work on Mac OSX Lion : json_encode ( (object) [ 'status' = (int) $newstatus ] ) After further debugging, problem: (object)[] : you can not cast a bracket array to object Parse error: unexpected '[' Test script: --- json_encode ( (object) [ 'status' = 4 ] ) -- Edit bug report at https://bugs.php.net/bug.php?id=64326edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64326r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64326r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64326r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64326r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64326r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64326r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64326r=needscript Try newer version: https://bugs.php.net/fix.php?id=64326r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64326r=support Expected behavior: https://bugs.php.net/fix.php?id=64326r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64326r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64326r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64326r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64326r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64326r=dst IIS Stability: https://bugs.php.net/fix.php?id=64326r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64326r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64326r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64326r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64326r=mysqlcfg
Bug #64299 [Nab]: Global variables not visible when using CLI
Edit report at https://bugs.php.net/bug.php?id=64299edit=1
ID: 64299
User updated by:andrew dot mof at gmail dot com
Reported by:andrew dot mof at gmail dot com
Summary:Global variables not visible when using CLI
Status: Not a bug
Type: Bug
Package:Variables related
Operating System: Ubuntu 12.10
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
All I can say is that the function cannot see the variable in CLI but can do
when its run by apache, which is why it confused me so much. My functions are
being included in a seperate file, does this affect the global scope in CLI?
Previous Comments:
[2013-02-28 16:05:33] anon at anon dot anon
@pajoye: register_globals has nothing to do with this; what are you saying?
That said, the test script appears to work perfectly. How could it not?
[2013-02-26 04:16:17] paj...@php.net
In PHP 4.2.0, the 'register_globals' setting default changed to
'off'. See http://www.php.net/release_4_2_0.php for more info.
We are sorry about the inconvenience, but this change was a necessary
part of our efforts to make PHP scripting more secure and portable.
There is no bug here. Works just fine.
[2013-02-25 21:50:34] andrew dot mof at gmail dot com
Description:
99% sure this is a bug. This code works fine when apache runs it but when I run
it though CLI it doesnt see the variable.
That said, this work:
$GLOBALS['jobID'] = 123;
Test script:
---
#!/usr/bin/php
?php
// In my script this function is included in a seperate file
function addLine() {
global $jobID;
echo $jobID;
}
$jobID = 123;
addLine();
--
Edit this bug report at https://bugs.php.net/bug.php?id=64299edit=1
Bug #64326 [Opn-Fbk]: Parse error on casting a bracket array to an object
Edit report at https://bugs.php.net/bug.php?id=64326edit=1 ID: 64326 Updated by: re...@php.net Reported by:f at worldhomes dot com Summary:Parse error on casting a bracket array to an object -Status: Open +Status: Feedback Type: Bug Package:*General Issues Operating System: Mac PHP Version:5.4.12 Block user comment: N Private report: N New Comment: There is no such error, see: http://3v4l.org/Qjk0T PHP = 5.4 works fine. Are you sure you are running 5.4.12? Previous Comments: [2013-02-28 16:11:03] f at worldhomes dot com Description: This code does not work on Mac OSX Lion : json_encode ( (object) [ 'status' = (int) $newstatus ] ) After further debugging, problem: (object)[] : you can not cast a bracket array to object Parse error: unexpected '[' Test script: --- json_encode ( (object) [ 'status' = 4 ] ) -- Edit this bug report at https://bugs.php.net/bug.php?id=64326edit=1
Req #13756 [Csd]: exponential ** operator
Edit report at https://bugs.php.net/bug.php?id=13756edit=1 ID: 13756 Updated by: ni...@php.net Reported by:san...@php.net Summary:exponential ** operator Status: Closed Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: n/a PHP Version:4.0.6 -Assigned To: +Assigned To:nikic Block user comment: N Private report: N New Comment: @tom Exponentiation is an operation that is used too little (in PHP) to warrant adding an extra operator for it. Doing a random guess, I'd think it's used even less than the bitwise operators (and those are used quite rarely in PHP...) Previous Comments: [2013-02-28 11:17:23] tom at r dot je Indeed! Seems very despotic just to say No. Deal with it with no further discussion or explanation why. [2012-07-08 23:31:23] hello at wesalvaro dot com le why not? [2002-04-27 16:17:03] j...@php.net not going to happen. just suck it up and use pow(). [2001-10-19 18:51:47] jer...@php.net I proposed that earlier (along with ^^) [ZendEnginge ML, june 27th july 3rd]. Anyway, I think it should be added, there is simply no power operator now, and pow() is both a bit bugly and overloaded (both ^^ and ** at the same time). [2001-10-19 11:24:28] hholz...@php.net ** is Pascal, not C 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=13756 -- Edit this bug report at https://bugs.php.net/bug.php?id=13756edit=1
Req #64320 [Opn-Fbk]: Proposal: deprecate the leading 0 means octal behaviour
Edit report at https://bugs.php.net/bug.php?id=64320edit=1 ID: 64320 Updated by: ni...@php.net Reported by:php at richardneill dot org Summary:Proposal: deprecate the leading 0 means octal behaviour -Status: Open +Status: Feedback Type: Feature/Change Request Package:Math related Operating System: All PHP Version:5.4.12 Block user comment: N Private report: N New Comment: Could you maybe provide a testcase for the behavior you are referring to? I tried out the following and 010 wasn't interpreted as octal in any case: var_dump((int) 010, intval(010), 010 == 8); // Outputs: int(10) int(10) bool(false) 010 is only treated as an octal if you write it out plainly (in the source code), like $foo = 010; Previous Comments: [2013-02-28 13:41:48] php at richardneill dot org Description: PHP assumes that a string with a leading zero should be interpreted as octal. In my experience, this is almost never useful, desirable, or intentional, however, it is a frequent trap for the beginner (or more experienced programmer), especially when parsing user-submitted data. The only reason for this behaviour seems to be historical, and compatibility with strtol(). When non-programmer humans write numbers with leading zeros, they don't usually mean base 8. My proposal is: 1. Introduce a new string format, 0o (letter o), to explicitly mean this is an octal number. This is similar to the recent introduction of 0b for binary numbers. [This part should be simple to do, and would also make the intentional use of octal notation explicit, increasing code-readability] 2. Add an option to raise E_NOTICE any time a number is implicitly interpreted as octal (for example $x = 0100). 3. In a few years time, (PHP 7?), it may finally be possible to change the default behaviour. Test script: --- Here's an illustration of a naive program that has data-dependent bugs that are really hard to track down. $mass_kg = 0.314 //user-submitted data, known to begin 0. $mass_g = substr ($mass_kg, 2); Yes, this is a silly thing to write. But it's a nasty trap for the unwary. The above example does what is expected, and might pass many tests. But if the user subsequently enters $mass_kg = 0.031, this will turn into 25 grams, not 31 grams. As a result, we have created a very subtle and hard to find bug. -- Edit this bug report at https://bugs.php.net/bug.php?id=64320edit=1
Bug #64322 [Opn-Nab]: $_ENV{PATH} does not work
Edit report at https://bugs.php.net/bug.php?id=64322edit=1
ID: 64322
Updated by: re...@php.net
Reported by:porton at narod dot ru
Summary:$_ENV{PATH} does not work
-Status: Open
+Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: Debian Linux
PHP Version:5.5Git-2013-02-28 (Git)
Block user comment: N
Private report: N
New Comment:
Please make sure you ini setting 'E' for $_ENV
http://www.php.net/manual/en/ini.core.php#ini.variables-order
withouth 'E' $_ENV will not been filled with environment variables
Previous Comments:
[2013-02-28 14:20:32] porton at narod dot ru
Description:
With Bash:
$ php -r 'echo $_ENV{PATH}, \n;'
PHP Notice: Undefined index: PATH in Command line code on line 1
The variable PATH is of course defined in my Bash.
Version info:
Debian Linux Wheezy
$ php --version
PHP 5.4.4-13 (cli) (built: Feb 19 2013 12:42:38)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
Test script:
---
php -r 'echo $_ENV{PATH}, \n;'
--
Edit this bug report at https://bugs.php.net/bug.php?id=64322edit=1
Req #64320 [Fbk-Csd]: Proposal: deprecate the leading 0 means octal behaviour
Edit report at https://bugs.php.net/bug.php?id=64320edit=1 ID: 64320 User updated by:php at richardneill dot org Reported by:php at richardneill dot org Summary:Proposal: deprecate the leading 0 means octal behaviour -Status: Feedback +Status: Closed Type: Feature/Change Request Package:Math related Operating System: All PHP Version:5.4.12 Block user comment: N Private report: N New Comment: You know, that bug has annoyed me for ages, since I got badly bitten by it about 7 years ago. In the meantime, I think it's been fixed! At any rate, I now agree with you that the current behaviour is correct, and that: PHP now treats strings with leading zeros (eg 0123) as decimal (123), rather than octal, even when automatically casting them. The documentation (in the sections: integers, casting) could perhaps be more explicit, given that: $a = 0x123; $b = 0x123 + 0; // $a and $b are equal $c = 0123; $d = 0123 + 0; // $c and $d are not equal. Sorry for the confusion - my bad. Previous Comments: [2013-02-28 17:14:36] ni...@php.net Could you maybe provide a testcase for the behavior you are referring to? I tried out the following and 010 wasn't interpreted as octal in any case: var_dump((int) 010, intval(010), 010 == 8); // Outputs: int(10) int(10) bool(false) 010 is only treated as an octal if you write it out plainly (in the source code), like $foo = 010; [2013-02-28 13:41:48] php at richardneill dot org Description: PHP assumes that a string with a leading zero should be interpreted as octal. In my experience, this is almost never useful, desirable, or intentional, however, it is a frequent trap for the beginner (or more experienced programmer), especially when parsing user-submitted data. The only reason for this behaviour seems to be historical, and compatibility with strtol(). When non-programmer humans write numbers with leading zeros, they don't usually mean base 8. My proposal is: 1. Introduce a new string format, 0o (letter o), to explicitly mean this is an octal number. This is similar to the recent introduction of 0b for binary numbers. [This part should be simple to do, and would also make the intentional use of octal notation explicit, increasing code-readability] 2. Add an option to raise E_NOTICE any time a number is implicitly interpreted as octal (for example $x = 0100). 3. In a few years time, (PHP 7?), it may finally be possible to change the default behaviour. Test script: --- Here's an illustration of a naive program that has data-dependent bugs that are really hard to track down. $mass_kg = 0.314 //user-submitted data, known to begin 0. $mass_g = substr ($mass_kg, 2); Yes, this is a silly thing to write. But it's a nasty trap for the unwary. The above example does what is expected, and might pass many tests. But if the user subsequently enters $mass_kg = 0.031, this will turn into 25 grams, not 31 grams. As a result, we have created a very subtle and hard to find bug. -- Edit this bug report at https://bugs.php.net/bug.php?id=64320edit=1
Req #64319 [PATCH]: max_input_vars warning unknown file
Edit report at https://bugs.php.net/bug.php?id=64319edit=1 ID: 64319 Patch added by: re...@php.net Reported by:david at davidsteinsland dot net Summary:max_input_vars warning unknown file Status: Open Type: Feature/Change Request Package:*General Issues Operating System: CentOS PHP Version:5.4.12 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: display-the-requested-script-file-name Revision: 1362075497 URL: https://bugs.php.net/patch-display.php?bug=64319patch=display-the-requested-script-file-namerevision=1362075497 Previous Comments: [2013-02-28 12:59:09] david at davidsteinsland dot net Description: When PHP raises a warning about max_input_vars being exceeded, it would be very helpful to see which file actually caused the error. The current error message just says Unknown on line 0. Expected result: Script file name Actual result: -- Unknown file -- Edit this bug report at https://bugs.php.net/bug.php?id=64319edit=1
Bug #64325 [Com]: Issue in automatic $_POST array handling
Edit report at https://bugs.php.net/bug.php?id=64325edit=1
ID: 64325
Comment by: re...@php.net
Reported by:php at sygmoral dot com
Summary:Issue in automatic $_POST array handling
Status: Open
Type: Bug
Package:Arrays related
Operating System: Debian
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
post_data = {'save[line[]]':'A line with text'}â
do you mean post_data = {'save[line][]':'A line with text'} ?
^^
is this you intention?
array(
'save' =
['line' =
['A line with text', 'maybe more lines']
]
); ?
Previous Comments:
[2013-02-28 16:09:49] php at sygmoral dot com
Description:
Php automatically puts POSTed name-value pairs with names ending in [] into
arrays. Very handy feature! However, I notice issues when more of those square
brackets are encountered.
If I send a name like `save[line[]]`, then `save` will be an array and the
first key in it will be `line[`, instead of `line[]`. It's not that I expect a
second level of arrays - just that it doesn't strangely remove that last
bracket.
So suppose we have the tiny php script below, and I send this with e.g. jquery:
post_data = {'save[line[]]':'A line with text'}
Effectively, the raw POST data being sent is:
save%5Bline%5B%5D%5D=A+line+with+text
Test script:
---
print_r(
$_POST['save']
);
Expected result:
POST: Array
(
[line[]] = A line with text
)
Actual result:
--
POST: Array
(
[line[] = A line with text
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64325edit=1
Bug #64324 [Nab]: Why 0 == 'BOOK' ?
Edit report at https://bugs.php.net/bug.php?id=64324edit=1
ID: 64324
User updated by:dosergio at ig dot com dot br
Reported by:dosergio at ig dot com dot br
Summary:Why 0 == 'BOOK' ?
Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: all
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I know the use of ===. The supposed 'bug' that I think exists, is comparing 0
to a non-empty String with double ==
My concern is because:
Observation 1: null, 0, 0, and all result as FALSE.
Observation 2: BUT... A STRING evaluates as TRUE.
SO...
0 == makes sense
BUT...
0 == A NON-EMPTY STRING makes no sense. IMHO False would be the right answer.
Take a little time to examine this:
if( 0 ) echo 0 works as TRUEbr; else echo 0 works as false br;
if( TEST) echo 'TEST' works as TRUEbr; else echo 'TEST' works as false
br;
if( 0 == 'TEST') echo But 0 == 'TEST' belies the statements above!;
Previous Comments:
[2013-02-28 15:22:59] ras...@php.net
You are doing a loose comparison between two different types. PHP has to pick a
type for it. In this case it does 0 == (int)'TEST' and casting 'TEST' to an int
is obviously going to give you 0. This is what you are going to want in most
cases. eg. 12 == 12 (with an extra space there). Chances are the 12 came
from user input since everything that comes from either the browser or your
backend database comes to you as strings, you are going to want that comparison
to work. If you cast both to strings instead they wouldn't.
If you don't want PHP to guess, use ===
[2013-02-28 14:55:44] dosergio at ig dot com dot br
*If the comparison WERE
[2013-02-28 14:54:24] dosergio at ig dot com dot br
Description:
If the comparison where
0 == '' that would make sense.
But I am chanlenging some PHP expert to convince us that the result 1 is right
for the comparison 0 == 'ANY STRING'
Test script:
---
if( 0 == 'TEST'){
echo PHP thinks 0 is equal 'TEST';
}
Expected result:
0 is not similar to a string that is NOT empty.
this comparison should return FALSE.
Actual result:
--
it returns 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=64324edit=1
Bug #64324 [Nab]: Why 0 == 'BOOK' ?
Edit report at https://bugs.php.net/bug.php?id=64324edit=1
ID: 64324
User updated by:dosergio at ig dot com dot br
Reported by:dosergio at ig dot com dot br
Summary:Why 0 == 'BOOK' ?
Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: all
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Conclusion:
The exact analysis above done in javascript says I am right.
I have no doubt that javascript makes more use of logic that php.
Previous Comments:
[2013-02-28 18:51:56] dosergio at ig dot com dot br
I know the use of ===. The supposed 'bug' that I think exists, is comparing 0
to a non-empty String with double ==
My concern is because:
Observation 1: null, 0, 0, and all result as FALSE.
Observation 2: BUT... A STRING evaluates as TRUE.
SO...
0 == makes sense
BUT...
0 == A NON-EMPTY STRING makes no sense. IMHO False would be the right answer.
Take a little time to examine this:
if( 0 ) echo 0 works as TRUEbr; else echo 0 works as false br;
if( TEST) echo 'TEST' works as TRUEbr; else echo 'TEST' works as false
br;
if( 0 == 'TEST') echo But 0 == 'TEST' belies the statements above!;
[2013-02-28 15:22:59] ras...@php.net
You are doing a loose comparison between two different types. PHP has to pick a
type for it. In this case it does 0 == (int)'TEST' and casting 'TEST' to an int
is obviously going to give you 0. This is what you are going to want in most
cases. eg. 12 == 12 (with an extra space there). Chances are the 12 came
from user input since everything that comes from either the browser or your
backend database comes to you as strings, you are going to want that comparison
to work. If you cast both to strings instead they wouldn't.
If you don't want PHP to guess, use ===
[2013-02-28 14:55:44] dosergio at ig dot com dot br
*If the comparison WERE
[2013-02-28 14:54:24] dosergio at ig dot com dot br
Description:
If the comparison where
0 == '' that would make sense.
But I am chanlenging some PHP expert to convince us that the result 1 is right
for the comparison 0 == 'ANY STRING'
Test script:
---
if( 0 == 'TEST'){
echo PHP thinks 0 is equal 'TEST';
}
Expected result:
0 is not similar to a string that is NOT empty.
this comparison should return FALSE.
Actual result:
--
it returns 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=64324edit=1
Bug #64267 [Fbk-Opn]: ldap_bind crash for ldaps://
Edit report at https://bugs.php.net/bug.php?id=64267edit=1 ID: 64267 User updated by:andrew+bugsphp at wimpyprogrammer dot com Reported by:andrew+bugsphp at wimpyprogrammer dot com Summary:ldap_bind crash for ldaps:// -Status: Feedback +Status: Open Type: Bug Package:LDAP related Operating System: Windows Server 2008 R2 x64 PHP Version:5.4.12 Block user comment: N Private report: N New Comment: I just retested this using snapshot r31a6f8b of PHP 5.12. The problem still occurs. The backtrace is below. Do I understand you correctly that the problem lies outside of the PHP files? I searched my entire system for *eay32.dll files and only found the ones (libeay32.dll and ssleay32.dll) in the PHP program files. I used Process Monitor to record any activity containing eay32.dll in the path. I recycled the IIS application pool and then ran the test script, and only the libeay32.dll and ssleay32.dll files in C:\PROGRA~2\PHP\PHP_5_4_12_r31a6f8b_NTS_x86\ were recorded. So I don't understand if this is something on my end or a problem with the 5.12 packages. If the problem is on my end, I'm surprised everything works on 5.11. Thank you! Thread 0 - System ID 2716 Entry point php_cgi+3a19 Create time 2/28/2013 1:05:07 PM Time spent in user mode 0 Days 0:0:0.625 Time spent in kernel mode 0 Days 0:0:0.187 Full Call Stack Function Arg 1 Arg 2 Arg 3 Arg 4 Source libeay32!OPENSSL_showfatal+c0 0001 0064 01a91c90 0031b80c g:\root\pvfsdev\windows\openssl-1.0.0d\crypto\cryptlib.c @ 831 + f libeay32!bn_mul_high+75f 01b198b4 01b198a4 01a91c90 0032e0ee g:\root\pvfsdev\windows\openssl-1.0.0d\crypto\bn\bn_mul.c @ 890 + 1e ssleay32!SSLv3_client_method+18c 01a91c90 01ae3df8 71c36bb8 01a91c90 ssleay32!SSL_free+19e 01a91c90 01ae3df8 71c4659b 01ae3df8 php_ldap!get_module+5bb8 01ae3df8 01ae3dd8 01ae3c38 71c46907 php_ldap!get_module+1559b 01ae3c38 71c552e8 0014 71b52dec php_ldap!get_module+15907 01ae3c38 01ae3c38 0157a190 php_ldap!get_module+16364 01ae3c38 0157a190 71c3b949 php_ldap!get_module+a7cd 0002 Exception Information LIBEAY32!OPENSSL_SHOWFATAL+C0In php- cgi__PID__1436__Date__02_28_2013__Time_01_05_08PM__534__Second_Chance_Exception_C 005.dmp the assembly instruction at libeay32!OPENSSL_showfatal+c0 in C:\Program Files (x86)\PHP\PHP_5_4_12_r31a6f8b_NTS_x86\libeay32.dll from The OpenSSL Project, http://www.openssl.org/ has caused an access violation exception (0xC005) when trying to write to memory location 0x0001 on thread 0 Module Information Image Name: C:\Program Files (x86)\PHP\PHP_5_4_12_r31a6f8b_NTS_x86\libeay32.dll Symbol Type: PDB Base address: 0x00905a4d Time Stamp: Wed Feb 13 05:36:27 2013 Checksum: 0x65006200 Comments: COM DLL: False Company Name: The OpenSSL Project, http://www.openssl.org/ ISAPIExtension: False File Description: OpenSSL Shared Library ISAPIFilter: False File Version: 0.9.8y Managed DLL: False Internal Name: libeay32 VB DLL: False Legal Copyright: Copyright © 1998-2007 The OpenSSL Project. Copyright © 1995-1998 Eric A. Young, Tim J. Hudson. All rights reserved. Loaded Image Name: libeay32.dll Legal Trademarks: Mapped Image Name: Original filename: libeay32.dll Module name: libeay32 Private Build: Single Threaded: False Product Name: The OpenSSL Toolkit Module Size: 1,020.00 KBytes Product Version: 0.9.8y Symbol File Name: c:\users\administrator\desktop\php-debug-pack-5.4.12-nts-win32- vc9-x86\libeay32.pdb Special Build: Previous Comments: [2013-02-22 04:31:26] paj...@php.net PHP is loading openssl 1.0.0 while it is built and requires 0.9.x series. That's the cause of the crash (openssl is very sensible and break ABI between these versions). Snapshots are available here: http://windows.php.net/downloads/snaps/php-5.4/ Please try again and be sure to only have openssl 0.9.x (bundled with the release) in the PATH used by the PHP processes. [2013-02-21 20:58:37] andrew+bugsphp at wimpyprogrammer dot com Here's the backtrace. I hope I captured it correctly. I struggled to find a debug file for libeay32.dll and ended up using http://www.orangefs.org/trac/orangefs/browser/branches/windows-client/openssl- windows/bin64/debug?rev=8844. Thanks! - Thread 0 - System ID 3660 Entry point php_cgi!mainCRTStartup Create time 2/21/2013 3:07:58 PM Time spent in user mode 0 Days 0:0:0.656 Time
Bug #64324 [Nab]: Why 0 == 'BOOK' ?
Edit report at https://bugs.php.net/bug.php?id=64324edit=1
ID: 64324
Updated by: ras...@php.net
Reported by:dosergio at ig dot com dot br
Summary:Why 0 == 'BOOK' ?
Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: all
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
We don't want a special case for 0. By your logic 12 == 'TEST' should be true.
You are assuming a cast to boolean even though neither side of the comparison
is
a boolean. Note that true == 'TEST' will match because here we cast to boolean.
But 'TEST' cast to an integer is going to give you 0.
Previous Comments:
[2013-02-28 18:58:51] dosergio at ig dot com dot br
Conclusion:
The exact analysis above done in javascript says I am right.
I have no doubt that javascript makes more use of logic that php.
[2013-02-28 18:51:56] dosergio at ig dot com dot br
I know the use of ===. The supposed 'bug' that I think exists, is comparing 0
to a non-empty String with double ==
My concern is because:
Observation 1: null, 0, 0, and all result as FALSE.
Observation 2: BUT... A STRING evaluates as TRUE.
SO...
0 == makes sense
BUT...
0 == A NON-EMPTY STRING makes no sense. IMHO False would be the right answer.
Take a little time to examine this:
if( 0 ) echo 0 works as TRUEbr; else echo 0 works as false br;
if( TEST) echo 'TEST' works as TRUEbr; else echo 'TEST' works as false
br;
if( 0 == 'TEST') echo But 0 == 'TEST' belies the statements above!;
[2013-02-28 15:22:59] ras...@php.net
You are doing a loose comparison between two different types. PHP has to pick a
type for it. In this case it does 0 == (int)'TEST' and casting 'TEST' to an int
is obviously going to give you 0. This is what you are going to want in most
cases. eg. 12 == 12 (with an extra space there). Chances are the 12 came
from user input since everything that comes from either the browser or your
backend database comes to you as strings, you are going to want that comparison
to work. If you cast both to strings instead they wouldn't.
If you don't want PHP to guess, use ===
[2013-02-28 14:55:44] dosergio at ig dot com dot br
*If the comparison WERE
[2013-02-28 14:54:24] dosergio at ig dot com dot br
Description:
If the comparison where
0 == '' that would make sense.
But I am chanlenging some PHP expert to convince us that the result 1 is right
for the comparison 0 == 'ANY STRING'
Test script:
---
if( 0 == 'TEST'){
echo PHP thinks 0 is equal 'TEST';
}
Expected result:
0 is not similar to a string that is NOT empty.
this comparison should return FALSE.
Actual result:
--
it returns 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=64324edit=1
Bug #64324 [Nab]: Why 0 == 'BOOK' ?
Edit report at https://bugs.php.net/bug.php?id=64324edit=1 ID: 64324 User updated by:dosergio at ig dot com dot br Reported by:dosergio at ig dot com dot br Summary:Why 0 == 'BOOK' ? Status: Not a bug Type: Bug Package:*General Issues Operating System: all PHP Version:Irrelevant Block user comment: N Private report: N New Comment: OK, you are right. That was the explanation I wanted: it depends on the type you compare. if( false == 'TEST') works correctly. Now it makes a little more sense to me. But javascript is still superior because inside a if() I suspect that any language should try to cast both to boolean. Previous Comments: [2013-02-28 19:04:24] ras...@php.net We don't want a special case for 0. By your logic 12 == 'TEST' should be true. You are assuming a cast to boolean even though neither side of the comparison is a boolean. Note that true == 'TEST' will match because here we cast to boolean. But 'TEST' cast to an integer is going to give you 0. [2013-02-28 18:58:51] dosergio at ig dot com dot br Conclusion: The exact analysis above done in javascript says I am right. I have no doubt that javascript makes more use of logic that php. [2013-02-28 18:51:56] dosergio at ig dot com dot br I know the use of ===. The supposed 'bug' that I think exists, is comparing 0 to a non-empty String with double == My concern is because: Observation 1: null, 0, 0, and all result as FALSE. Observation 2: BUT... A STRING evaluates as TRUE. SO... 0 == makes sense BUT... 0 == A NON-EMPTY STRING makes no sense. IMHO False would be the right answer. Take a little time to examine this: if( 0 ) echo 0 works as TRUEbr; else echo 0 works as false br; if( TEST) echo 'TEST' works as TRUEbr; else echo 'TEST' works as false br; if( 0 == 'TEST') echo But 0 == 'TEST' belies the statements above!; [2013-02-28 15:22:59] ras...@php.net You are doing a loose comparison between two different types. PHP has to pick a type for it. In this case it does 0 == (int)'TEST' and casting 'TEST' to an int is obviously going to give you 0. This is what you are going to want in most cases. eg. 12 == 12 (with an extra space there). Chances are the 12 came from user input since everything that comes from either the browser or your backend database comes to you as strings, you are going to want that comparison to work. If you cast both to strings instead they wouldn't. If you don't want PHP to guess, use === [2013-02-28 14:55:44] dosergio at ig dot com dot br *If the comparison WERE 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=64324 -- Edit this bug report at https://bugs.php.net/bug.php?id=64324edit=1
Bug #64325 [Opn]: Issue in automatic $_POST array handling
Edit report at https://bugs.php.net/bug.php?id=64325edit=1
ID: 64325
User updated by:php at sygmoral dot com
Reported by:php at sygmoral dot com
Summary:Issue in automatic $_POST array handling
Status: Open
Type: Bug
Package:Arrays related
Operating System: Debian
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
Thank you for your reaction!
But no: I did in fact mean what I wrote. I realise it's a strange data
structure, so here's a short explanation for it: the 'save' array holds a
collection of html form elements that are not yet to be submitted, but should
be saved temporarily into some other set of memory, so that upon the next
visit, those temporary values can be easily inserted into the displayed form,
without having been submitted. In other words, it's for a form that remembers
its state throughout visits.
So I send an object containing the name-value pairs in the form, and send that
over POST. In the example used here, this results in one or more name-value
pairs that are saved into the save array, as save['line[]'] = value.
And that is the situation that triggers this bug, as in my original post. I'm
sure there are other ways to achieve what I want, but I figured I'd report it
since this does not look as if it's intended.
Note that the example is a simplification of my application, where multiple
'single' and 'array' values are saved.
Previous Comments:
[2013-02-28 18:22:57] re...@php.net
post_data = {'save[line[]]':'A line with text'}â
do you mean post_data = {'save[line][]':'A line with text'} ?
^^
is this you intention?
array(
'save' =
['line' =
['A line with text', 'maybe more lines']
]
); ?
[2013-02-28 16:09:49] php at sygmoral dot com
Description:
Php automatically puts POSTed name-value pairs with names ending in [] into
arrays. Very handy feature! However, I notice issues when more of those square
brackets are encountered.
If I send a name like `save[line[]]`, then `save` will be an array and the
first key in it will be `line[`, instead of `line[]`. It's not that I expect a
second level of arrays - just that it doesn't strangely remove that last
bracket.
So suppose we have the tiny php script below, and I send this with e.g. jquery:
post_data = {'save[line[]]':'A line with text'}
Effectively, the raw POST data being sent is:
save%5Bline%5B%5D%5D=A+line+with+text
Test script:
---
print_r(
$_POST['save']
);
Expected result:
POST: Array
(
[line[]] = A line with text
)
Actual result:
--
POST: Array
(
[line[] = A line with text
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64325edit=1
[PHP-BUG] Bug #64327 [NEW]: is_file, file_exists, is_readable fail on special characters
From: ashwini at majestik dot net
Operating system: Windows Server 2003
PHP version: Irrelevant
Package: Filesystem function related
Bug Type: Bug
Bug description:is_file, file_exists, is_readable fail on special characters
Description:
---
From manual page:
http://www.php.net/function.is-file#refsect1-function.is-file-description
---
The is_file, file_exists and is_readable functions fail in Windows even if
the file actually does exist, if the file name contains a special
character. This happens because of the encoding of the .php file itself
that executes the is_file function, if the .php file is encoded with UTF-8
then the above commands incorrectly fail.
If instead the .php file is encoded with Western (Windows 1252) then the
file with the special character is found and is_file/file_exists/etc return
correctly.
Tested under IIS 6 w/ PHP 5.2.4 on Windows Server 2003.
Test script:
---
?
$my_picture=photos/fullsize/Djañgo.jpg;
if (is_file($my_picture)) {
echo picture found!;
} else {
echo picture NOT found! $my_picture;
}
?
--
Edit bug report at https://bugs.php.net/bug.php?id=64327edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64327r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64327r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64327r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64327r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64327r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64327r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64327r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64327r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64327r=support
Expected behavior: https://bugs.php.net/fix.php?id=64327r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64327r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64327r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64327r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64327r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64327r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64327r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64327r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64327r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64327r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64327r=mysqlcfg
Bug #64314 [Com]: imagettfbbox loads wrong fontname if using ../ and underscore in font name
Edit report at https://bugs.php.net/bug.php?id=64314edit=1 ID: 64314 Comment by: mail+php at requinix dot net Reported by:ctcrmcou at opm dot gov Summary:imagettfbbox loads wrong fontname if using ../ and underscore in font name Status: Open Type: Bug Package:GD related Operating System: W7 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: This is quite unusual, to see a filename being treated differently depending whether it has an underscore. Can you include a complete, hopefully smallish script demonstrating the problem? That way someone (like me) can grab a handful of font files and look for the cause. Previous Comments: [2013-02-27 20:28:09] ctcrmcou at opm dot gov Description: Assuming a subdirectory named fonts contains 30 fonts named font_1.ttf - font_30.ttf, calling imagettfbox with a fontname such as ../fonts/font_10.ttf loads incorrect font, the number part is somehow being altered and the wrong font is loading. Somehow the combination of ../ and _ in the finename param are screwing things up. This is not a file/font not found error. This is the font that loads font_13.ttf is actually loading font_14.ttf, or font_28.ttf is loading font_10.ttf. I can only guess the underscore is changing the meaning of the number or the number is being converted. Test script: --- Works: $box=imagettfbbox(100,0,fonts/font_10.ttf,some text); Doesn't work (wrong font loads): $box=imagettfbbox(100,0,../fonts/font_10.ttf,some text); Workaround 1: remove underscore from font names $box=imagettfbbox(100,0,../fonts/font10.ttf,some text); Workaround 2: move app that loads font to higher directory level (no ../ in path) $box=imagettfbbox(100,0,fonts/font_10.ttf,some text); -- Edit this bug report at https://bugs.php.net/bug.php?id=64314edit=1
Bug #64314 [Opn]: imagettfbbox loads wrong fontname if using ../ and underscore in font name
Edit report at https://bugs.php.net/bug.php?id=64314edit=1 ID: 64314 User updated by:ctcrmcou at opm dot gov Reported by:ctcrmcou at opm dot gov Summary:imagettfbbox loads wrong fontname if using ../ and underscore in font name Status: Open Type: Bug Package:GD related Operating System: W7 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I'd be happy to but it will be a few days before I can get to it. Previous Comments: [2013-02-28 22:15:29] mail+php at requinix dot net This is quite unusual, to see a filename being treated differently depending whether it has an underscore. Can you include a complete, hopefully smallish script demonstrating the problem? That way someone (like me) can grab a handful of font files and look for the cause. [2013-02-27 20:28:09] ctcrmcou at opm dot gov Description: Assuming a subdirectory named fonts contains 30 fonts named font_1.ttf - font_30.ttf, calling imagettfbox with a fontname such as ../fonts/font_10.ttf loads incorrect font, the number part is somehow being altered and the wrong font is loading. Somehow the combination of ../ and _ in the finename param are screwing things up. This is not a file/font not found error. This is the font that loads font_13.ttf is actually loading font_14.ttf, or font_28.ttf is loading font_10.ttf. I can only guess the underscore is changing the meaning of the number or the number is being converted. Test script: --- Works: $box=imagettfbbox(100,0,fonts/font_10.ttf,some text); Doesn't work (wrong font loads): $box=imagettfbbox(100,0,../fonts/font_10.ttf,some text); Workaround 1: remove underscore from font names $box=imagettfbbox(100,0,../fonts/font10.ttf,some text); Workaround 2: move app that loads font to higher directory level (no ../ in path) $box=imagettfbbox(100,0,fonts/font_10.ttf,some text); -- Edit this bug report at https://bugs.php.net/bug.php?id=64314edit=1
Req #39598 [Com]: error verification after fwrite()
Edit report at https://bugs.php.net/bug.php?id=39598edit=1 ID: 39598 Comment by: gauthi...@php.net Reported by:max at nucleus dot it Summary:error verification after fwrite() Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Linux PHP Version:5.2.0 Block user comment: N Private report: N New Comment: Here's a simple reproduce test case: http://labs.silverorange.com/files/php-bug39598/php-bug-39598-test.phps In this case, and EPIPE occurs. The fwrite call writes 0 bytes. No error code is available and no PHP error is raised. Previous Comments: [2006-11-22 22:53:31] max at nucleus dot it Description: The documentation states tha fwrite() returns false in case of error, but it doesn't do so if the actual write fails. For example if I asynchronously write to a pipe (such as those obtained by proc_open()) I and the pipe is not ready or is broken, fwrite() returns 0. This could be a correct behaviour it I had a way to determine the error. The problem is that EAGAIN or EPIPE are completely impossible to determine and I can't know if I need to wait or I have to close the stream. A possible solution would be to implement ferror() or errno. Reproduce code: --- $Proc = proc_open($Cmd, $Streams, $Pipes, $CWD, $Env); stream_set_blocking($Pipes[0], 0); $Result = fwrite($Pipes[0], test); // If $Pipes[0] is not ready to receive data // $Result is 0, but I can't know why. // The real code I'm writing involves // stream_select() and repeated reads and writes // on multiple pipes. Expected result: fwrite() should return 0 when the stream is asynchrounous, the C write() returns 0 and errno is EAGAIN. fwrite() should return false in all other cases where the C write() returns 0. Alternatively a way to access ferror() or errno is needed. -- Edit this bug report at https://bugs.php.net/bug.php?id=39598edit=1
[PHP-BUG] Bug #64328 [NEW]: No results when re-executing PDO dblib query using same variable
From: brad at wcubed dot net
Operating system: FreeBSD 9.1 amd64
PHP version: 5.4.12
Package: PDO related
Bug Type: Bug
Bug description:No results when re-executing PDO dblib query using same variable
Description:
Environment:
MS SQL Server 2008 R2
FreeTSD 0.64_9,1
No results are returned from dblib PDO::query() + PDOStatement::fetchAll()
if the same variable is re-used from a previous query/fetch.
If the variable is unset() before the second query, the behavior is as
expected.
This problem is reproducible on both a fresh install of FreeBSD 9.1 and
longstanding 8.2 install. This behavior was not evident on the FreeBSD 8.2
install prior to a php upgrade from 5.3.8 to 5.4.12.
Test script:
---
$dbh = new PDO(dblib:host=$host;dbname=$dbname, $user, $pass);
$create = $dbh-exec('DROP TABLE foo');
$create = $dbh-exec('CREATE TABLE foo (ID int PRIMARY KEY IDENTITY (1,1)
NOT NULL, bar VARCHAR(10))');
$insert = $dbh-exec('INSERT INTO foo (bar) VALUES (\'baz\')');
$qry = 'select * from foo';
$stmt = $dbh-query($qry);
$results = $stmt-fetchAll(PDO::FETCH_NUM);
print_r($results);
$stmt = $dbh-query($qry);
$results = $stmt-fetchAll(PDO::FETCH_NUM);
print_r($results);
unset($stmt);
$stmt = $dbh-query($qry);
$results = $stmt-fetchAll(PDO::FETCH_NUM);
print_r($results);
Expected result:
Array
(
[0] = Array
(
[0] = 1
[1] = baz
)
)
Array
(
)
Array
(
[0] = Array
(
[0] = 1
[1] = baz
)
)
Actual result:
--
Array
(
[0] = Array
(
[0] = 1
[1] = baz
)
)
Array
(
[0] = Array
(
[0] = 1
[1] = baz
)
)
Array
(
[0] = Array
(
[0] = 1
[1] = baz
)
)
--
Edit bug report at https://bugs.php.net/bug.php?id=64328edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64328r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64328r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64328r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64328r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64328r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64328r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64328r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64328r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64328r=support
Expected behavior: https://bugs.php.net/fix.php?id=64328r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64328r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64328r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64328r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64328r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64328r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64328r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64328r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64328r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64328r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64328r=mysqlcfg
Req #64319 [Opn-Wfx]: max_input_vars warning unknown file
Edit report at https://bugs.php.net/bug.php?id=64319edit=1 ID: 64319 Updated by: larue...@php.net Reported by:david at davidsteinsland dot net Summary:max_input_vars warning unknown file -Status: Open +Status: Wont fix Type: Feature/Change Request Package:*General Issues Operating System: CentOS PHP Version:5.4.12 Block user comment: N Private report: N New Comment: I don't think there is one way to find out which file caused the error, since it is caused by the client who send the request. so actually this most useful info will be the referer: PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0, referer: https://.comm/index.php; and when this warning raise, it still at `startup` phase, no really script be executed. so IMO 'Unknown on line' make sense . and the reeze's patch won't help much more. there are a lots of applications are single entry, thinking about the ZF application etc. so the patch will make nothing useful but cause confuse. and do you really need more than 1000 vars be accepted? if in that case, I think you should opitimize your application.. mark as won't fix. Previous Comments: [2013-02-28 18:18:17] re...@php.net The following patch has been added/updated: Patch Name: display-the-requested-script-file-name Revision: 1362075497 URL: https://bugs.php.net/patch-display.php?bug=64319patch=display-the-requested-script-file-namerevision=1362075497 [2013-02-28 12:59:09] david at davidsteinsland dot net Description: When PHP raises a warning about max_input_vars being exceeded, it would be very helpful to see which file actually caused the error. The current error message just says Unknown on line 0. Expected result: Script file name Actual result: -- Unknown file -- Edit this bug report at https://bugs.php.net/bug.php?id=64319edit=1
Bug #64297 [Opn-Fbk]: Segfault after allowed memory exhausted
Edit report at https://bugs.php.net/bug.php?id=64297edit=1 ID: 64297 Updated by: larue...@php.net Reported by:jille at hexon dot cx Summary:Segfault after allowed memory exhausted -Status: Open +Status: Feedback Type: Bug Package:Reproducible crash Operating System: Linux PHP Version:5.4.12 Block user comment: N Private report: N New Comment: do you get the new valgrind log? thanks Previous Comments: [2013-02-25 15:51:09] jille at hexon dot cx Removing the memcache extension doesn't help. (gdb output seems the same, do you want the new valgrind output? (Takes a while)) [2013-02-25 14:56:49] larue...@php.net please remove the memcache extension then test it again. [2013-02-25 13:48:45] jille at hexon dot cx Description: PHP crashes with a segmentation fault when we allocate more memory than allowed. This happens in 5.4.9 as well as 5.4.12. (No other versions tested.) The only Different SAPI's yield different behaviours: * cli prints the OOM-error and sends it to syslog and segfaults immediately. * cli in gdb or valgrind doesn't print it but syslogs and segfaults the same. * apache2handler immediately sends the OOM-error to syslog but gives an error (Cannot redeclare class Bummer) and segfaults afterwards on the next request to that child. The class Bummer is included from our auto_prepend_file and I'm sure it isn't accidentally included twice. Funny thing is sometimes the error is about a different class (sometimes not even one that was loaded by the auto_prepend_file but just with a require()) so my guess would be some kind of memory corruption. I can reproduce this reliably but failed to create a small reproduction script and unfortunately can't publish the source of our libraries. Actual result: -- The OOM-error: PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 32 bytes) in /path/to/libs/bpm.lib on line 3190 GDB: Program received signal SIGSEGV, Segmentation fault. _zend_mm_free_int (heap=0xfb0510, p=0x403aeda8) at /tmp/php-5.4.12/Zend/zend_alloc.c:2071 2071size = ZEND_MM_BLOCK_SIZE(mm_block); (gdb) bt #0 _zend_mm_free_int (heap=0xfb0510, p=0x403aeda8) at /tmp/php-5.4.12/Zend/zend_alloc.c:2071 #1 0x007a3992 in destroy_op_array (op_array=0x11f1640) at /tmp/php-5.4.12/Zend/zend_opcode.c:356 #2 0x007bb288 in zend_hash_destroy (ht=0xfb0e20) at /tmp/php-5.4.12/Zend/zend_hash.c:560 #3 0x007ad491 in zend_shutdown () at /tmp/php-5.4.12/Zend/zend.c:822 #4 0x0074ec4a in php_module_shutdown () at /tmp/php-5.4.12/main/main.c:2365 #5 0x00433c07 in main (argc=5, argv=0x7fffe648) at /tmp/php-5.4.12/sapi/cli/php_cli.c:1379 $ valgrind ./sapi/cli/php /path/to/memcrash.php ==5742== Memcheck, a memory error detector ==5742== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==5742== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==5742== Command: ./sapi/cli/php /path/to/memcrash.php ==5742== ==5742== Conditional jump or move depends on uninitialised value(s) ==5742==at 0x4E3B4E0: inflateReset2 (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4) ==5742==by 0x4E3B5D8: inflateInit2_ (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4) ==5742==by 0x4E364F5: uncompress (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4) ==5742==by 0x71E239: mmc_unpack_value (memcache_pool.c:337) ==5742==by 0x723CF3: mmc_server_read_value (memcache_ascii_protocol.c:189) ==5742==by 0x720732: mmc_pool_select (memcache_pool.c:1584) ==5742==by 0x7211A7: mmc_pool_run (memcache_pool.c:1670) ==5742==by 0x719635: zif_memcache_get (memcache.c:1669) ==5742==by 0x853B58: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642) ==5742==by 0x80E00E: execute (zend_vm_execute.h:410) ==5742==by 0x7AEF56: zend_execute_scripts (zend.c:1315) ==5742==by 0x74EEE2: php_execute_script (main.c:2492) ==5742== ==5742== Invalid read of size 8 ==5742==at 0x78717D: _zend_mm_free_int (zend_alloc.c:2071) ==5742==by 0x7A3991: destroy_op_array (zend_opcode.c:356) ==5742==by 0x7BB287: zend_hash_destroy (zend_hash.c:560) ==5742==by 0x7AD490: zend_shutdown (zend.c:822) ==5742==by 0x74EC49: php_module_shutdown (main.c:2365) ==5742==by 0x433C06: main (php_cli.c:1379) ==5742== Address 0x500031c0 is not stack'd, malloc'd or (recently) free'd ==5742== ==5742== ==5742== Process terminating with default action of signal 11 (SIGSEGV) ==5742== Access not within mapped region at address 0x500031C0 ==5742==at 0x78717D: _zend_mm_free_int (zend_alloc.c:2071) ==5742==by 0x7A3991: destroy_op_array
Bug #64325 [Opn-Fbk]: Issue in automatic $_POST array handling
Edit report at https://bugs.php.net/bug.php?id=64325edit=1
ID: 64325
Updated by: larue...@php.net
Reported by:php at sygmoral dot com
Summary:Issue in automatic $_POST array handling
-Status: Open
+Status: Feedback
Type: Bug
Package:Arrays related
Operating System: Debian
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
PHP won't allow variables name to contains [, . etc , so I think this is
really a narrow usage.
but, however I do believe there is a bug.
a patch will be attached. but I need to ask someone else's opinion before
commit
it.
thanks
Previous Comments:
[2013-02-28 19:45:57] php at sygmoral dot com
Thank you for your reaction!
But no: I did in fact mean what I wrote. I realise it's a strange data
structure, so here's a short explanation for it: the 'save' array holds a
collection of html form elements that are not yet to be submitted, but should
be saved temporarily into some other set of memory, so that upon the next
visit, those temporary values can be easily inserted into the displayed form,
without having been submitted. In other words, it's for a form that remembers
its state throughout visits.
So I send an object containing the name-value pairs in the form, and send that
over POST. In the example used here, this results in one or more name-value
pairs that are saved into the save array, as save['line[]'] = value.
And that is the situation that triggers this bug, as in my original post. I'm
sure there are other ways to achieve what I want, but I figured I'd report it
since this does not look as if it's intended.
Note that the example is a simplification of my application, where multiple
'single' and 'array' values are saved.
[2013-02-28 18:22:57] re...@php.net
post_data = {'save[line[]]':'A line with text'}â
do you mean post_data = {'save[line][]':'A line with text'} ?
^^
is this you intention?
array(
'save' =
['line' =
['A line with text', 'maybe more lines']
]
); ?
[2013-02-28 16:09:49] php at sygmoral dot com
Description:
Php automatically puts POSTed name-value pairs with names ending in [] into
arrays. Very handy feature! However, I notice issues when more of those square
brackets are encountered.
If I send a name like `save[line[]]`, then `save` will be an array and the
first key in it will be `line[`, instead of `line[]`. It's not that I expect a
second level of arrays - just that it doesn't strangely remove that last
bracket.
So suppose we have the tiny php script below, and I send this with e.g. jquery:
post_data = {'save[line[]]':'A line with text'}
Effectively, the raw POST data being sent is:
save%5Bline%5B%5D%5D=A+line+with+text
Test script:
---
print_r(
$_POST['save']
);
Expected result:
POST: Array
(
[line[]] = A line with text
)
Actual result:
--
POST: Array
(
[line[] = A line with text
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64325edit=1
Bug #64325 [PATCH]: Issue in automatic $_POST array handling
Edit report at https://bugs.php.net/bug.php?id=64325edit=1
ID: 64325
Patch added by: larue...@php.net
Reported by:php at sygmoral dot com
Summary:Issue in automatic $_POST array handling
Status: Feedback
Type: Bug
Package:Arrays related
Operating System: Debian
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug64325.patch
Revision: 1362108583
URL:
https://bugs.php.net/patch-display.php?bug=64325patch=bug64325.patchrevision=1362108583
Previous Comments:
[2013-03-01 03:29:02] larue...@php.net
PHP won't allow variables name to contains [, . etc , so I think this is
really a narrow usage.
but, however I do believe there is a bug.
a patch will be attached. but I need to ask someone else's opinion before
commit
it.
thanks
[2013-02-28 19:45:57] php at sygmoral dot com
Thank you for your reaction!
But no: I did in fact mean what I wrote. I realise it's a strange data
structure, so here's a short explanation for it: the 'save' array holds a
collection of html form elements that are not yet to be submitted, but should
be saved temporarily into some other set of memory, so that upon the next
visit, those temporary values can be easily inserted into the displayed form,
without having been submitted. In other words, it's for a form that remembers
its state throughout visits.
So I send an object containing the name-value pairs in the form, and send that
over POST. In the example used here, this results in one or more name-value
pairs that are saved into the save array, as save['line[]'] = value.
And that is the situation that triggers this bug, as in my original post. I'm
sure there are other ways to achieve what I want, but I figured I'd report it
since this does not look as if it's intended.
Note that the example is a simplification of my application, where multiple
'single' and 'array' values are saved.
[2013-02-28 18:22:57] re...@php.net
post_data = {'save[line[]]':'A line with text'}â
do you mean post_data = {'save[line][]':'A line with text'} ?
^^
is this you intention?
array(
'save' =
['line' =
['A line with text', 'maybe more lines']
]
); ?
[2013-02-28 16:09:49] php at sygmoral dot com
Description:
Php automatically puts POSTed name-value pairs with names ending in [] into
arrays. Very handy feature! However, I notice issues when more of those square
brackets are encountered.
If I send a name like `save[line[]]`, then `save` will be an array and the
first key in it will be `line[`, instead of `line[]`. It's not that I expect a
second level of arrays - just that it doesn't strangely remove that last
bracket.
So suppose we have the tiny php script below, and I send this with e.g. jquery:
post_data = {'save[line[]]':'A line with text'}
Effectively, the raw POST data being sent is:
save%5Bline%5B%5D%5D=A+line+with+text
Test script:
---
print_r(
$_POST['save']
);
Expected result:
POST: Array
(
[line[]] = A line with text
)
Actual result:
--
POST: Array
(
[line[] = A line with text
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64325edit=1
Bug #64328 [Opn]: No results when re-executing PDO dblib query using same variable
Edit report at https://bugs.php.net/bug.php?id=64328edit=1
ID: 64328
User updated by:brad at wcubed dot net
Reported by:brad at wcubed dot net
Summary:No results when re-executing PDO dblib query using
same variable
Status: Open
Type: Bug
Package:PDO related
Operating System: FreeBSD 9.1 amd64
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
Reverse the expected and actual results. The second fetchAll() returns an empty
array.
Previous Comments:
[2013-03-01 01:18:36] brad at wcubed dot net
Description:
Environment:
MS SQL Server 2008 R2
FreeTSD 0.64_9,1
No results are returned from dblib PDO::query() + PDOStatement::fetchAll() if
the same variable is re-used from a previous query/fetch.
If the variable is unset() before the second query, the behavior is as expected.
This problem is reproducible on both a fresh install of FreeBSD 9.1 and
longstanding 8.2 install. This behavior was not evident on the FreeBSD 8.2
install prior to a php upgrade from 5.3.8 to 5.4.12.
Test script:
---
$dbh = new PDO(dblib:host=$host;dbname=$dbname, $user, $pass);
$create = $dbh-exec('DROP TABLE foo');
$create = $dbh-exec('CREATE TABLE foo (ID int PRIMARY KEY IDENTITY (1,1) NOT
NULL, bar VARCHAR(10))');
$insert = $dbh-exec('INSERT INTO foo (bar) VALUES (\'baz\')');
$qry = 'select * from foo';
$stmt = $dbh-query($qry);
$results = $stmt-fetchAll(PDO::FETCH_NUM);
print_r($results);
$stmt = $dbh-query($qry);
$results = $stmt-fetchAll(PDO::FETCH_NUM);
print_r($results);
unset($stmt);
$stmt = $dbh-query($qry);
$results = $stmt-fetchAll(PDO::FETCH_NUM);
print_r($results);
Expected result:
Array
(
[0] = Array
(
[0] = 1
[1] = baz
)
)
Array
(
)
Array
(
[0] = Array
(
[0] = 1
[1] = baz
)
)
Actual result:
--
Array
(
[0] = Array
(
[0] = 1
[1] = baz
)
)
Array
(
[0] = Array
(
[0] = 1
[1] = baz
)
)
Array
(
[0] = Array
(
[0] = 1
[1] = baz
)
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64328edit=1
[PHP-BUG] Bug #64329 [NEW]: CURLOPT_FTP_SKIP_PASV_IP does not exist
From: daniel at c-books dot co dot uk Operating system: any PHP version: 5.4.12 Package: *General Issues Bug Type: Bug Bug description:CURLOPT_FTP_SKIP_PASV_IP does not exist Description: he CURLOPT_FTP_SKIP_PASV_IP option is part of libcurl (see http://curl.haxx.se/libcurl/c/curl_easy_setopt.html ) but no predefined constant exists for use with curl_setopt(). This was requested 2010-01-14. https://bugs.php.net/bug.php?id=50756 No resolution has been provided to date. -- Edit bug report at https://bugs.php.net/bug.php?id=64329edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64329r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64329r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64329r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64329r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64329r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64329r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64329r=needscript Try newer version: https://bugs.php.net/fix.php?id=64329r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64329r=support Expected behavior: https://bugs.php.net/fix.php?id=64329r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64329r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64329r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64329r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64329r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64329r=dst IIS Stability: https://bugs.php.net/fix.php?id=64329r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64329r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64329r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64329r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64329r=mysqlcfg
Bug #64329 [Opn-Nab]: CURLOPT_FTP_SKIP_PASV_IP does not exist
Edit report at https://bugs.php.net/bug.php?id=64329edit=1 ID: 64329 Updated by: pierr...@php.net Reported by:daniel at c-books dot co dot uk Summary:CURLOPT_FTP_SKIP_PASV_IP does not exist -Status: Open +Status: Not a bug Type: Bug Package:*General Issues Operating System: any PHP Version:5.4.12 Block user comment: N Private report: N New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. This constant will be available in php5.5 Previous Comments: [2013-03-01 04:28:33] daniel at c-books dot co dot uk Description: he CURLOPT_FTP_SKIP_PASV_IP option is part of libcurl (see http://curl.haxx.se/libcurl/c/curl_easy_setopt.html ) but no predefined constant exists for use with curl_setopt(). This was requested 2010-01-14. https://bugs.php.net/bug.php?id=50756 No resolution has been provided to date. -- Edit this bug report at https://bugs.php.net/bug.php?id=64329edit=1
Bug #64329 [Com]: CURLOPT_FTP_SKIP_PASV_IP does not exist
Edit report at https://bugs.php.net/bug.php?id=64329edit=1 ID: 64329 Comment by: daniel at c-books dot co dot uk Reported by:daniel at c-books dot co dot uk Summary:CURLOPT_FTP_SKIP_PASV_IP does not exist Status: Not a bug Type: Bug Package:*General Issues Operating System: any PHP Version:5.4.12 Block user comment: N Private report: N New Comment: I am confused how am I not using a current version of PHP? PHP Info: PHP Version 5.4.12 PHP Downloads: PHP 5.4.12 (Current stable) Previous Comments: [2013-03-01 04:41:35] pierr...@php.net Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. This constant will be available in php5.5 [2013-03-01 04:28:33] daniel at c-books dot co dot uk Description: he CURLOPT_FTP_SKIP_PASV_IP option is part of libcurl (see http://curl.haxx.se/libcurl/c/curl_easy_setopt.html ) but no predefined constant exists for use with curl_setopt(). This was requested 2010-01-14. https://bugs.php.net/bug.php?id=50756 No resolution has been provided to date. -- Edit this bug report at https://bugs.php.net/bug.php?id=64329edit=1
