#46727 [Opn->Bgs]: For loop doesn't work as expected with decimals
ID: 46727
Updated by: [EMAIL PROTECTED]
Reported By: grant at tattomedia dot com
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Linux
PHP Version: 5.3CVS-2008-12-01 (snap)
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/en/language.types.float.php and the
instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2008-12-02 05:44:55] [EMAIL PROTECTED]
This is because at the last iteration, the value for $val is (at least
on my 5.2.6 test system; php 5.3.0 returns me the same value):
2.000444089209850062616169452667236328125
This is > 2, which means "<= 2" is false.
If I dump the values of $val for each iteration:
0
0.155511151231257827021181583404541015625
0.200011102230246251565404236316680908203125
0.3000444089209850062616169452667236328125
0.40002220446049250313080847263336181640625
0.5
0.59997779553950749686919152736663818359375
0.6999555910790149937383830547332763671875
0.79993338661852249060757458209991455078125
0.899911182158029987476766109466552734375
0.99988897769753748434595763683319091796875
1.0998667732370449812151491641998291015625
1.1999555910790149937383830547332763671875
1.3000444089209850062616169452667236328125
1.4001332267629550187848508358001708984375
1.5002220446049250313080847263336181640625
1.6003108624468950438313186168670654296875
1.7003996802888650563545525074005126953125
1.8004884981308350688777863979339599609375
1.9005773159728050814010202884674072265625
Your "best" option would be to round($val, 1) before checking, but it
might prove to be expensive. This is why it's always tricky to work with
float values.
[2008-12-01 21:11:29] grant at tattomedia dot com
Description:
My PHP version is PHP 5.2.5 (cli): This wasn't listed in the select.
It seems that a for loop that deals with floats has bad logic when
evaluating equivalence against another number (in my situation an int).
Reproduce code:
---
$values = array();
for ($val = 0; $val <= 2; $val = $val + .1) {
$values[] = $val;
}
print_r($values);
Expected result:
Array ( [0] => 0 [1] => 0.1 [2] => 0.2 [3] => 0.3 [4] => 0.4 [5] => 0.5
[6] => 0.6 [7] => 0.7 [8] => 0.8 [9] => 0.9 [10] => 1 [11] => 1.1 [12]
=> 1.2 [13] => 1.3 [14] => 1.4 [15] => 1.5 [16] => 1.6 [17] => 1.7 [18]
=> 1.8 [19] => 1.9 [20] => 2 )
Actual result:
--
Array ( [0] => 0 [1] => 0.1 [2] => 0.2 [3] => 0.3 [4] => 0.4 [5] => 0.5
[6] => 0.6 [7] => 0.7 [8] => 0.8 [9] => 0.9 [10] => 1 [11] => 1.1 [12]
=> 1.2 [13] => 1.3 [14] => 1.4 [15] => 1.5 [16] => 1.6 [17] => 1.7 [18]
=> 1.8 [19] => 1.9 )
--
Edit this bug report at http://bugs.php.net/?id=46727&edit=1
#46727 [Opn]: For loop doesn't work as expected with decimals
ID: 46727
Updated by: [EMAIL PROTECTED]
Reported By: grant at tattomedia dot com
Status: Open
Bug Type: Unknown/Other Function
Operating System: Linux
PHP Version: 5.3CVS-2008-12-01 (snap)
New Comment:
This is because at the last iteration, the value for $val is (at least
on my 5.2.6 test system; php 5.3.0 returns me the same value):
2.000444089209850062616169452667236328125
This is > 2, which means "<= 2" is false.
If I dump the values of $val for each iteration:
0
0.155511151231257827021181583404541015625
0.200011102230246251565404236316680908203125
0.3000444089209850062616169452667236328125
0.40002220446049250313080847263336181640625
0.5
0.59997779553950749686919152736663818359375
0.6999555910790149937383830547332763671875
0.79993338661852249060757458209991455078125
0.899911182158029987476766109466552734375
0.99988897769753748434595763683319091796875
1.0998667732370449812151491641998291015625
1.1999555910790149937383830547332763671875
1.3000444089209850062616169452667236328125
1.4001332267629550187848508358001708984375
1.5002220446049250313080847263336181640625
1.6003108624468950438313186168670654296875
1.7003996802888650563545525074005126953125
1.8004884981308350688777863979339599609375
1.9005773159728050814010202884674072265625
Your "best" option would be to round($val, 1) before checking, but it
might prove to be expensive. This is why it's always tricky to work with
float values.
Previous Comments:
[2008-12-01 21:11:29] grant at tattomedia dot com
Description:
My PHP version is PHP 5.2.5 (cli): This wasn't listed in the select.
It seems that a for loop that deals with floats has bad logic when
evaluating equivalence against another number (in my situation an int).
Reproduce code:
---
$values = array();
for ($val = 0; $val <= 2; $val = $val + .1) {
$values[] = $val;
}
print_r($values);
Expected result:
Array ( [0] => 0 [1] => 0.1 [2] => 0.2 [3] => 0.3 [4] => 0.4 [5] => 0.5
[6] => 0.6 [7] => 0.7 [8] => 0.8 [9] => 0.9 [10] => 1 [11] => 1.1 [12]
=> 1.2 [13] => 1.3 [14] => 1.4 [15] => 1.5 [16] => 1.6 [17] => 1.7 [18]
=> 1.8 [19] => 1.9 [20] => 2 )
Actual result:
--
Array ( [0] => 0 [1] => 0.1 [2] => 0.2 [3] => 0.3 [4] => 0.4 [5] => 0.5
[6] => 0.6 [7] => 0.7 [8] => 0.8 [9] => 0.9 [10] => 1 [11] => 1.1 [12]
=> 1.2 [13] => 1.3 [14] => 1.4 [15] => 1.5 [16] => 1.6 [17] => 1.7 [18]
=> 1.8 [19] => 1.9 )
--
Edit this bug report at http://bugs.php.net/?id=46727&edit=1
#46727 [NEW]: For loop doesn't work as expected with decimals
From: grant at tattomedia dot com
Operating system: Linux
PHP version: 5.3CVS-2008-12-01 (snap)
PHP Bug Type: Unknown/Other Function
Bug description: For loop doesn't work as expected with decimals
Description:
My PHP version is PHP 5.2.5 (cli): This wasn't listed in the select.
It seems that a for loop that deals with floats has bad logic when
evaluating equivalence against another number (in my situation an int).
Reproduce code:
---
$values = array();
for ($val = 0; $val <= 2; $val = $val + .1) {
$values[] = $val;
}
print_r($values);
Expected result:
Array ( [0] => 0 [1] => 0.1 [2] => 0.2 [3] => 0.3 [4] => 0.4 [5] => 0.5
[6] => 0.6 [7] => 0.7 [8] => 0.8 [9] => 0.9 [10] => 1 [11] => 1.1 [12] =>
1.2 [13] => 1.3 [14] => 1.4 [15] => 1.5 [16] => 1.6 [17] => 1.7 [18] => 1.8
[19] => 1.9 [20] => 2 )
Actual result:
--
Array ( [0] => 0 [1] => 0.1 [2] => 0.2 [3] => 0.3 [4] => 0.4 [5] => 0.5
[6] => 0.6 [7] => 0.7 [8] => 0.8 [9] => 0.9 [10] => 1 [11] => 1.1 [12] =>
1.2 [13] => 1.3 [14] => 1.4 [15] => 1.5 [16] => 1.6 [17] => 1.7 [18] => 1.8
[19] => 1.9 )
--
Edit bug report at http://bugs.php.net/?id=46727&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46727&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46727&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46727&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46727&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46727&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46727&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46727&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46727&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46727&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46727&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46727&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46727&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46727&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46727&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46727&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46727&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46727&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46727&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46727&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46727&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46727&r=mysqlcfg
#45392 [Asn]: ob_start()/ob_end_clean() and memory_limit
ID: 45392 Updated by: [EMAIL PROTECTED] Reported By: flebron at bumeran dot com Status: Assigned Bug Type: Output Control Operating System: * PHP Version: 5CVS-2008-11-01 Assigned To: iliaa New Comment: Works fine for me using your example script in 5.3, the patch never went into 5.2 as it is a little risky for a stable release. Previous Comments: [2008-11-02 13:58:27] [EMAIL PROTECTED] The test for this bug fails in both branches. [2008-09-17 00:20:51] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2008-07-14 11:26:09] [EMAIL PROTECTED] This slightly modified script shows the bug without massive output: [2008-06-29 22:30:08] flebron at bumeran dot com Description: When memory_limit is reached, and one is using the output buffering functions, instead of just dying with an "out of memory" error, the contents of the buffer are spilled onto stdout. The output_buffering ini setting wasn't set to any particular limit. Reproduce code: --- http://bugs.php.net/?id=45392&edit=1
#40926 [Opn->Ana]: shared pgsql and curl extensions cause segfault
ID: 40926 Updated by: [EMAIL PROTECTED] Reported By: seanius at debian dot org -Status: Open +Status: Analyzed Bug Type: PostgreSQL related Operating System: Debian GNU/Linux PHP Version: 5.2CVS-2008-05-15 -Assigned To: +Assigned To: hholzgra New Comment: This is being worked on on the PG side, see "libpq callback unregistration" on http://wiki.postgresql.org/wiki/CommitFest_2008-11#Clients Previous Comments: [2008-10-28 22:27:52] [EMAIL PROTECTED] yohgaki seems to have left us so de-assigning. [2008-03-01 14:17:22] jbq at caraldi dot com Another workaround is to recompile PostgreSQL's libpq without OpenSSL support (ie the --with-openssl configure switch). After all, OpenSSL is rarely needed in a typical LAPP installation. [2007-11-12 14:45:13] sam at zoy dot org Hello, I did read the sources and studied them, and I can confirm that it is a matter of callback jumping to an invalid address. libpq's init_ssl_system() installs callbacks by calling CRYPTO_set_id_callback() and CRYPTO_set_locking_callback(). This function is called each time initialize_SSL() is called (for instance through the PHP pg_connect() function) and does not keep a reference counter, so libpq's destroy_SSL() has no way to know that it should call a destroy_ssl_system() function, and there is no such function anyway. So the callbacks are never removed. But then, upon cleanup, PHP calls zend_shutdown() which properly unloads pgsql.so and therefore the unused libpq. Finally, the zend_shutdown procedure calls zm_shutdown_curl() which in turn calls curl_global_cleanup() which leads to an ERR_free_strings() call and eventually a CRYPTO_lock() call. CRYPTO_lock() checks whether there are any callbacks to call, finds one (the one installed by libpg), calls it, and crashes because libpq was unloaded and hence the callback is no longer in mapped memory. There are a few ways to fix the problem, all of which are highly unsatisfying or irrealist: - always ensure that pgsql.so is loaded before (and therefore unloaded after) any other SSL-using library. - fix libpq so that it keeps a reference count when initialize_SSL() is called, updates it when destroy_SSL() is called, and remove SSL callbacks when the reference count reaches zero. - fix libpq so that it removes the SSL callbacks when unloaded (done in the library's .fini section) - hack PHP's module_destructor() so that it does not unload a module if its name was pgsql.so (or maybe there is already a mechanism for that). None of these proposals is really safe because there might be other conflicts due to libssl not being context-aware. There is also the possibility to fix libssl by making it reentrant or context-aware (just kidding, lol). In all cases, libssl can be copiously blamed. [2007-03-26 22:00:20] [EMAIL PROTECTED] Assigned to the maintainer. See also bug #36152. [2007-03-26 21:42:29] seanius at debian dot org Description: note that this might not be a bug in php, but php is certainly affected by it so it's worth at least a bogus entry in your db so other people can google their way to it. if you compile curl and pgsql as shared extensions and then load them in the same order from php.ini, any script that establishes a postgres connection will result in a segfault before the script quits. the problem seems to be that the postgresql libpq library registers a callback function (pq_lockingcallback) for openssl-related locking. around exit time, when php unloads the various extensions, if any modules reference openssl routines in their shutdown methods that indirectly call openssl locking routines, the ssl library will try and call the callback function, which now points at invalid memory since the libpq library has already been dlclose()'d somewhere. if it's been closed directly by php (you guys would know better than me) then i'd say it's a php bug, but if it's closed indirectly by some pq shutdown routine, then you're just innocent victims. anyway, there's a pretty simple workaround for the time being. if you reverse the module loading so order so that pgsql is loaded first (and thus unloaded last by the current php engine), then the callback function never references invalid memory and no segfault happens. btw this was reported a couple times in the debian bts, most of the information can be found at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411982 (this is for 5.2.0, but i've verified it against the latest 5.2.1 as well) also, i found #36152 in your bts after writing this up, but it seems that
#46699 [Opn->Ver]: xml_parse fails with Bus Error only when parser is namespace aware.
ID: 46699 Updated by: [EMAIL PROTECTED] Reported By: m dot haarmann at gmail dot com -Status: Open +Status: Verified Bug Type: XML related Operating System: Mac OS 10.5.5 PHP Version: 5.2CVS-2008-11-28 Previous Comments: [2008-11-30 22:40:17] crrodriguez at opensuse dot org Reproduced consistently in linux 64 bit. (5_2 and 5_3) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f697a693710 (LWP 31187)] #0 0x in ?? () #1 0x00757e32 in _start_element_handler_ns (user=0xfde0c0, name=0xff3a23 "stylesheet", prefix=0xff3a1f "xsl", URI=0xff3a36 "http://www.w3.org/1999/XSL/Transform";, nb_namespaces=2, namespaces=0xff4030, nb_attributes=1, nb_defaulted=0, attributes=0xff3e30) at /home/cristian/php5/ext/xml/compat.c:131 #2 0x7f6978743dd8 in ?? () from /usr/lib64/libxml2.so.2 #3 0x7f697874a281 in xmlParseChunk () from /usr/lib64/libxml2.so.2 #4 0x007588ea in php_XML_Parse (parser=0xfde0c0, data=0xfdb318 "\n, "xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\"; \nxmlns:foo=\"http://momo/\";>\n\n\t http://www.w3.org/1999/XSL/Transform"; xmlns:foo="http://momo/";> node [2008-11-28 13:30:45] [EMAIL PROTECTED] Ok, is that demo.xml available somewhere? [2008-11-28 12:58:12] m dot haarmann at gmail dot com still same error with snapshot. [2008-11-28 12:29:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/46699 -- Edit this bug report at http://bugs.php.net/?id=46699&edit=1
#46707 [Opn->Csd]: i undeclared in function mysqlnd_fetch_row_async_buffered mysqlnd_result.lo
ID: 46707 Updated by: [EMAIL PROTECTED] Reported By: e dot hoekstra at daisycon dot com -Status: Open +Status: Closed Bug Type: MySQL related Operating System: RedHat Enterprise 4 PHP Version: 5.3.0alpha2 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-11-28 11:40:09] e dot hoekstra at daisycon dot com Without --enable-mysqlnd-threading everything's fine [2008-11-28 11:30:33] e dot hoekstra at daisycon dot com Description: /root/PHP/5.3.0/php-5.3.0alpha2/ext/mysqlnd/mysqlnd_result.c: In function `mysqlnd_fetch_row_async_buffered': /root/PHP/5.3.0/php-5.3.0alpha2/ext/mysqlnd/mysqlnd_result.c:1387: error: `i' undeclared (first use in this function) /root/PHP/5.3.0/php-5.3.0alpha2/ext/mysqlnd/mysqlnd_result.c:1387: error: (Each undeclared identifier is reported only once /root/PHP/5.3.0/php-5.3.0alpha2/ext/mysqlnd/mysqlnd_result.c:1387: error: for each function it appears in.) -- -- -- /bin/sh /root/PHP/5.3.0/php-5.3.0alpha2/libtool --silent --preserve-dup-deps --mode=compile /root/PHP/5.3.0/php-5.3.0alpha2/meta_ccld -Iext/mysqlnd/ -I/root/PHP/5.3.0/php-5.3.0alpha2/ext/mysqlnd/ -DPHP_ATOM_INC -I/root/PHP/5.3.0/php-5.3.0alpha2/include -I/root/PHP/5.3.0/php-5.3.0alpha2/main -I/root/PHP/5.3.0/php-5.3.0alpha2 -I/root/PHP/5.3.0/php-5.3.0alpha2/ext/ereg/regex -I/usr/include/libxml2 -I/root/PHP/5.3.0/php-5.3.0alpha2/ext/date/lib -I/root/PHP/5.3.0/php-5.3.0alpha2/ext/mbstring/oniguruma -I/root/PHP/5.3.0/php-5.3.0alpha2/ext/mbstring/libmbfl -I/root/PHP/5.3.0/php-5.3.0alpha2/ext/mbstring/libmbfl/mbfl -I/root/PHP/5.3.0/php-5.3.0alpha2/TSRM -I/root/PHP/5.3.0/php-5.3.0alpha2/Zend-I/usr/include -g -O2 -DZTS -c /root/PHP/5.3.0/php-5.3.0alpha2/ext/mysqlnd/mysqlnd_result.c -o ext/mysqlnd/mysqlnd_result.lo /root/PHP/5.3.0/php-5.3.0alpha2/ext/mysqlnd/mysqlnd_result.c: In function `mysqlnd_fetch_row_async_buffered': /root/PHP/5.3.0/php-5.3.0alpha2/ext/mysqlnd/mysqlnd_result.c:1387: error: `i' undeclared (first use in this function) /root/PHP/5.3.0/php-5.3.0alpha2/ext/mysqlnd/mysqlnd_result.c:1387: error: (Each undeclared identifier is reported only once /root/PHP/5.3.0/php-5.3.0alpha2/ext/mysqlnd/mysqlnd_result.c:1387: error: for each function it appears in.) make: *** [ext/mysqlnd/mysqlnd_result.lo] Error 1 Reproduce code: --- ./configure --enable-mysqlnd-threading --disable-tokenizer --enable-sockets --disable-posix --disable-phar --without-pdo-sqlite --with-pdo-mysql=mysqlnd --with-mysql=mysqlnd --enable-mbstring --disable-flatfile --disable-filter --enable-ftp --enable-bcmath --with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d --libdir=/usr/lib64 --with-libxml-dir=/usr/lib64 -- Edit this bug report at http://bugs.php.net/?id=46707&edit=1
#44686 [Com]: SOAP-ERROR: Parsing WSDL
ID: 44686 Comment by: sergio dot aghemo at fiat dot com Reported By: dmittner at llnw dot com Status: No Feedback Bug Type: SOAP related Operating System: Gentoo PHP Version: 5.2.5 New Comment: having the same problem. Urgent fix needed! follow extract of the WSDL . Previous Comments: [2008-11-30 18:22:10] olivier at quatrain dot com Having the same problem happening with a valid WSDL on php 5.2.5 and 5.2.6, I tested it on the latest snapshot of PHP (5.2.7RC6) and got the same error. Hope it helps. [2008-10-29 01:00:02] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-10-21 11:27:41] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-04-14 22:42:28] dmittner at llnw dot com I've narrowed it down, I think. Relevant excerpts from the WSDL: ... ... No "name" is specified in the upper block of XML, for the line with the "ref=". If I specify a name the WSDL parses. I believe the correct behavior would be for PHP to acquire the name from the complexType declaration. I don't know if this should always be the case for references, or only when no name is provided - if providing a name is even valid for them. This is just a guess, though. I've dealt very little with references so do not know the standards surrounding them; only what digging into the XML has revealed. [2008-04-11 05:54:01] dmittner at llnw dot com I have also found this to occur on PHP 5.0.5, also on Gentoo. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/44686 -- Edit this bug report at http://bugs.php.net/?id=44686&edit=1
#46672 [Com]: Cloned SimpleXML Output Different
ID: 46672
Comment by: rfludwick at gmail dot com
Reported By: rfludwick at gmail dot com
Status: Feedback
Bug Type: SimpleXML related
Operating System: Gentoo Linux
PHP Version: 5.2.6
New Comment:
Still broken in that snapshot.
Previous Comments:
[2008-11-27 02:01:56] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-11-25 23:35:36] rfludwick at gmail dot com
Description:
It appears that cloning a SimpleXML object will not produce the same
XML output on asXML() as the original object. The original will output
the XML header and a line break after the XML while the cloned object is
missing these.
Reproduce code:
---
");
$simplexml->path->to->node = "Zend";
$simplexml_2 = clone $simplexml;
echo "|{$simplexml->asXML()}|\n|{$simplexml_2->asXML()}|";
Expected result:
|
Zend
|
|
Zend
|
Actual result:
--
|
Zend
|
|Zend|
--
Edit this bug report at http://bugs.php.net/?id=46672&edit=1
#45989 [Opn]: json_decode() passes through certain invalid JSON strings
ID: 45989
Updated by: [EMAIL PROTECTED]
Reported By: steven at acko dot net
Status: Open
Bug Type: JSON related
Operating System: Mac OS X
PHP Version: 5.2.6
New Comment:
Just to add to this:
I know that the function is not supposed to be a JSON validator, but
it's supposed to return the string as is -- in case it's a literal type,
but why does it in some cases return "null" then?
For example:
$bad_json = "{ 'bar': 'baz' }";
json_decode($bad_json); // null
I know this is "probably" an edge-case but $bad_json could be my own
/valid/ string -- not valid JSON. Because a string could look like
anything. Point well taken, I'm passing in a pretty /funky/ looking
string. But instead of "NULL", json_decode should return the string
as-is.
That is, according to the documentation, a bug. ;-)
Lots of people also seemed to rely on json_decode as a json validator.
Which is -- once you understand the subtle differences -- not the case.
The case should be made for either one though.
Previous Comments:
[2008-11-17 15:23:35] [EMAIL PROTECTED]
@Iliaa:
Could this bug be re-evaluated or a more detailed explaination as of
why the docs sometimes note that "NULL" is returned on invalid json, and
why sometimes json_decode() returns the string instead?
If the function returns "whatever" then the docs should be updated to
tell the user to not rely on what is returned by json_decode at all.
;-)
I double-checked some of Steve's examples on jsonlint.com (which is in
most docs cited as the reference validator for json data) and they all
show up as "invalid".
I also build the most recent 5.2.7 snapshot:
./configure --disable-all --enable-json
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php test-45989.php
string(14) "'invalid json'"
string(12) "invalid json"
string(2) " {"
string(2) " ["
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php --ini
Configuration File (php.ini) Path: /usr/local/lib
Loaded Configuration File: (none)
Scan for additional .ini files in: (none)
Additional .ini files parsed: (none)
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php -m
[PHP Modules]
date
json
Reflection
standard
[Zend Modules]
I'm gonna write a test and send it to QA too.
[2008-09-10 01:14:23] steven at acko dot net
Please clarify the bogus classification.
The following each returns NULL, as expected:
var_dump(json_decode('[')); // unmatched bracket
var_dump(json_decode('{')); // unmatched brace
var_dump(json_decode('{}}')); // unmatched brace
var_dump(json_decode('{error error}')); // invalid object key/value
notation
var_dump(json_decode('["\"]')); // unclosed string
var_dump(json_decode('[" \x "]')); // invalid escape code
Yet the following each returns the literal argument as a string:
var_dump(json_decode(' ['));
var_dump(json_decode(' {'));
var_dump(json_decode(' {}}'));
var_dump(json_decode(' {error error}'));
var_dump(json_decode('"\"'));
var_dump(json_decode('" \x "'));
Please examine the examples closely: they are all meaningless, invalid
JSON. Even under the
most widely stretched definition of JSON, the above is not JSON encoded
data. Yet
json_decode() arbitarily returns /some of it/ as a string... and in a
way that looks
suspiciously like a bad parser implementation.
If this was merely a case of json_decode() returning /all/ invalid json
as is, then it could
be classified as an implementation quirk. But because of how
inconsistent it is now, you
can't say that it is by design or following any kind of spec.
E.g. how would you currently see if json_decode() succeeded or not?
[2008-09-10 00:38:09] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
.
[2008-09-04 00:32:20] steven at acko dot net
Description:
When json_decode() is given certain invalid JSON strings, it will
return
the literal string as the result, rather than returning NULL.
Note: in #38680, the decision was made to allow json_decode() to accept
literal basic types (strings, ints, ...) even though this is not
allowed
by RFC 4627 (which only allows objects/arrays). This bug report is
different because even under the PHP interpretation of JSON, these
strings can not be considered valid, and trivial variations on them do
in fact throw an error as expected.
(The non-standard behaviour introduced in #38680 is not documented at
all by the way, which is kind of ironic given the numerous issues that
have 'go
#42849 [Com]: Configuration File (php.ini) Path incorrect
ID: 42849 Comment by: rafael dot amador at gmail dot com Reported By: inglis-php at yahoo dot com dot au Status: No Feedback Bug Type: *General Issues Operating System: win xp pro PHP Version: 5.2.4 New Comment: Bug #39191 Previous Comments: [2008-12-01 15:55:46] rafael dot amador at gmail dot com Bug #37919 PHP < The same bug [2007-10-13 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2007-10-05 15:23:16] [EMAIL PROTECTED] Exactly what does phpinfo() have about php.ini? There are 2 places in the output, paste both here..(in the very beginning of the output..) [2007-10-04 07:37:01] inglis-php at yahoo dot com dot au Description: I have just used the .msi file to install php 5.2.4 All appeared to work well. I installed to c:\PHP folder. Then wrote a small .php test file (below) and tried it and the noticed that: The phpinfo() function is reporting php.ini file as being in the 'C:\Windows' directory. It is actually located in 'C:\PHP' directory. I have searched my c drive and there is only one copy of php.ini and it is in the c:\PHP directory. I assume it finds the php.ini via the path environment which now starts with c:\PHP. Reproduce code: --- PHP Test Hello World'; ?> Expected result: C:\PHP Actual result: -- C:\Windows -- Edit this bug report at http://bugs.php.net/?id=42849&edit=1
#42849 [Com]: Configuration File (php.ini) Path incorrect
ID: 42849 Comment by: rafael dot amador at gmail dot com Reported By: inglis-php at yahoo dot com dot au Status: No Feedback Bug Type: *General Issues Operating System: win xp pro PHP Version: 5.2.4 New Comment: Bug #37919 PHP < The same bug Previous Comments: [2007-10-13 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2007-10-05 15:23:16] [EMAIL PROTECTED] Exactly what does phpinfo() have about php.ini? There are 2 places in the output, paste both here..(in the very beginning of the output..) [2007-10-04 07:37:01] inglis-php at yahoo dot com dot au Description: I have just used the .msi file to install php 5.2.4 All appeared to work well. I installed to c:\PHP folder. Then wrote a small .php test file (below) and tried it and the noticed that: The phpinfo() function is reporting php.ini file as being in the 'C:\Windows' directory. It is actually located in 'C:\PHP' directory. I have searched my c drive and there is only one copy of php.ini and it is in the c:\PHP directory. I assume it finds the php.ini via the path environment which now starts with c:\PHP. Reproduce code: --- PHP Test Hello World'; ?> Expected result: C:\PHP Actual result: -- C:\Windows -- Edit this bug report at http://bugs.php.net/?id=42849&edit=1
#46725 [NEW]: strpos extensions with array type parameters
From: php at pk dot freesurf dot fr Operating system: PHP version: 5.2.6 PHP Bug Type: Feature/Change Request Bug description: strpos extensions with array type parameters Description: a) strpos($haystack, $t_needle, $offset) will return position of the first $t_needle element found ... b) strpos($t_haystack, $t_needle, $t_offset) will return an array of corresponding position... the a) will be very usefull for me ( very cpu time consuming when $t_haystack is about 1 MB and sizeof($t_needle) is great, the haystack is to be scan as many times as the sizeof($t_needle) when I do this within a loop with the current strpos implementation). Then proposal will need only 1 time scanning ... and it could be possible to optimize the search by pre-scanning the $t_needle array and generate an "automate" that will search for 1 character and then the 2nd one to be just after, and so on... the b) suggestion is only for the code "beauty"... (forgive my poor english, I'm french...) -- Edit bug report at http://bugs.php.net/?id=46725&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46725&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46725&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46725&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46725&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46725&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46725&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46725&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46725&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46725&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46725&r=support Expected behavior: http://bugs.php.net/fix.php?id=46725&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46725&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46725&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46725&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46725&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46725&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46725&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46725&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46725&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46725&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46725&r=mysqlcfg
#45940 [Com]: MySQLI OO does not populate connect_error property on failed connect
ID: 45940
Comment by: dannyrjohnston at msn dot com
Reported By: talmage dot news at gmail dot com
Status: Assigned
Bug Type: MySQLi related
Operating System: Centos 5
PHP Version: 5.2.6
Assigned To: mysql
New Comment:
Forget my previous comment. I found some code between the new mysqli
statement in the example I was using which was setting the $dbObj to
false if mysql_connect_error was returning a value.
Previous Comments:
[2008-12-01 13:17:14] dannyrjohnston at msn dot com
I have duplicated this issue.
According to the manual mysqli::__construct should always return a
object, but the function is returning a false value on error.
I have tried three different possible error conditions and have the
following results:
Bad user/password combo: mysqli_connect_error() returns "Access
denied for user 'xxx'@'xxx' (using password: YES)", return value is
false.
User does not have access to the db selected:
mysqli_connect_error()returns "Access denied for user 'xxx'@'xxx' to
database 'xxx'", return value is false.
Bad port number: mysqli_connect_error() returns "Can't connect to
MySQL server on 'localhost' (10061)", return value is false.
I have not checked any other cases such as bad socked name, but in each
of the above conditions I received a false value not an object.
test code:
error result:
dbObj=bool(false)
sucess result:
dbObj==object(mysqli)#1 (0) {
}
[2008-11-29 00:22:45] valentin71 at gmail dot com
Not quite sure that mudroeb is right.
According to manual the right call format must be following:
mysqli mysqli_connect ( [string host [, string username [, string
passwd [, string dbname [, int port [, string socket]] )
However
conn=new mysqli('localhost','user','password','my_db',3306);
works as expected.
[2008-11-29 00:08:06] mudroeb at gmail dot com
Get the same problem but make investigation:
$mysqli = new mysqli("localhost:3307", "my_user", "my_password",
"world");
-> got error
$mysqli = new mysqli("127.0.0.1:3307", "my_user", "my_password",
"world");
-> got error
BUT!:
$mysqli = new mysqli("127.0.0.1:3306", "my_user", "my_password",
"world");
-> change server port to default (3306).
$mysqli = new mysqli("localhost", "my_user", "my_password",
"world");
-> all works correct.
Seems that variable not parsed for $HOST_NAME and $PORT_NUMBER and
function try to connect using incorrect (not parsed) string.
[2008-08-29 11:51:21] [EMAIL PROTECTED]
I can reproduce that, assigning to mysql folks.
[2008-08-29 03:59:12] talmage dot news at gmail dot com
Upgrading to snap did not fix.
[EMAIL PROTECTED] src]# /usr/local/php/bin/php -v
PHP 5.2.7-dev (cli) (built: Aug 28 2008 20:54:37)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
[EMAIL PROTECTED] src]# /usr/local/php/bin/php -q test.php
Warning: mysqli::mysqli(): (HY000/2005): Unknown MySQL server host
'127.0.0.1:3307' (3) in /srv/php/projects/test/src/test.php on line 4
Warning: main(): Couldn't fetch mysqli in
/srv/php/projects/test/src/test.php on line 7
Warning: main(): Couldn't fetch mysqli in
/srv/php/projects/test/src/test.php on line 12
Host information:
Warning: mysqli::close(): Couldn't fetch mysqli in
/srv/php/projects/test/src/test.php on line 15
[EMAIL PROTECTED] src]#
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/45940
--
Edit this bug report at http://bugs.php.net/?id=45940&edit=1
#37919 [Bgs]: PHP doesn't read the configurations propertly
ID: 37919 User updated by: rafael dot amador at gmail dot com Reported By: rafael dot amador at gmail dot com Status: Bogus Bug Type: IIS related Operating System: Windows XP Pro SP2 PHP Version: 5.2.3 New Comment: i invite everyona that sufred from this bug post a comment to express the problem and vote i hope that the php team resolve this bug. This bug is more than 3 years old and PHP team has flagged it as "BOGUS" as a quickly way to discard it and not to resolve it as should be Previous Comments: [2008-12-01 13:28:40] rafael dot amador at gmail dot com THIS BUGS ISN'T FIXED... WHY YOU GUYS TRY to understand the bug ... this is anoting in the current version the PROBLEM YET Occurs [2007-07-24 21:53:21] rafael dot amador at gmail dot com how can be that in the phpinfo shows me two diferents setting Configuration File (php.ini) PathC:\WINDOWS Loaded Configuration File(none) And _SERVER["DOCUMENT_ROOT"] = "c:\inetpub\wwwroot" _ENV["Path"] = "C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Archivos de programa\QuickTime\QTSystem\;C:\php" ehhh i added the path how is specified in the install text or modify your install instruction to SHOW EXACTLY how you need to config your system to use PATH setting in PHP or fix this bug ... [2007-07-24 21:49:19] rafael dot amador at gmail dot com ... i followed every instruction in Install.txt then iit's not my fault is a bug ... install IIS and Install PHP and check it ... you are flaging wrong this bug ... [2007-07-24 12:04:03] [EMAIL PROTECTED] Misconfiguration of your system is not any bug in PHP.. [2007-07-23 12:22:09] rafael dot amador at gmail dot com As you requested ... Configuration File (php.ini) PathC:\WINDOWS Loaded Configuration File(none) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/37919 -- Edit this bug report at http://bugs.php.net/?id=37919&edit=1
#37919 [Bgs]: PHP doesn't read the configurations propertly
ID: 37919 User updated by: rafael dot amador at gmail dot com Reported By: rafael dot amador at gmail dot com Status: Bogus Bug Type: IIS related Operating System: Windows XP Pro SP2 PHP Version: 5.2.3 New Comment: THIS BUGS ISN'T FIXED... WHY YOU GUYS TRY to understand the bug ... this is anoting in the current version the PROBLEM YET Occurs Previous Comments: [2007-07-24 21:53:21] rafael dot amador at gmail dot com how can be that in the phpinfo shows me two diferents setting Configuration File (php.ini) PathC:\WINDOWS Loaded Configuration File(none) And _SERVER["DOCUMENT_ROOT"] = "c:\inetpub\wwwroot" _ENV["Path"] = "C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Archivos de programa\QuickTime\QTSystem\;C:\php" ehhh i added the path how is specified in the install text or modify your install instruction to SHOW EXACTLY how you need to config your system to use PATH setting in PHP or fix this bug ... [2007-07-24 21:49:19] rafael dot amador at gmail dot com ... i followed every instruction in Install.txt then iit's not my fault is a bug ... install IIS and Install PHP and check it ... you are flaging wrong this bug ... [2007-07-24 12:04:03] [EMAIL PROTECTED] Misconfiguration of your system is not any bug in PHP.. [2007-07-23 12:22:09] rafael dot amador at gmail dot com As you requested ... Configuration File (php.ini) PathC:\WINDOWS Loaded Configuration File(none) [2007-07-22 23:26:45] [EMAIL PROTECTED] What does phpinfo() have in the "Loaded configuration file" section? And above that, what does it have the path set to? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/37919 -- Edit this bug report at http://bugs.php.net/?id=37919&edit=1
#45940 [Com]: MySQLI OO does not populate connect_error property on failed connect
ID: 45940
Comment by: dannyrjohnston at msn dot com
Reported By: talmage dot news at gmail dot com
Status: Assigned
Bug Type: MySQLi related
Operating System: Centos 5
PHP Version: 5.2.6
Assigned To: mysql
New Comment:
I have duplicated this issue.
According to the manual mysqli::__construct should always return a
object, but the function is returning a false value on error.
I have tried three different possible error conditions and have the
following results:
Bad user/password combo: mysqli_connect_error() returns "Access
denied for user 'xxx'@'xxx' (using password: YES)", return value is
false.
User does not have access to the db selected:
mysqli_connect_error()returns "Access denied for user 'xxx'@'xxx' to
database 'xxx'", return value is false.
Bad port number: mysqli_connect_error() returns "Can't connect to
MySQL server on 'localhost' (10061)", return value is false.
I have not checked any other cases such as bad socked name, but in each
of the above conditions I received a false value not an object.
test code:
error result:
dbObj=bool(false)
sucess result:
dbObj==object(mysqli)#1 (0) {
}
Previous Comments:
[2008-11-29 00:22:45] valentin71 at gmail dot com
Not quite sure that mudroeb is right.
According to manual the right call format must be following:
mysqli mysqli_connect ( [string host [, string username [, string
passwd [, string dbname [, int port [, string socket]] )
However
conn=new mysqli('localhost','user','password','my_db',3306);
works as expected.
[2008-11-29 00:08:06] mudroeb at gmail dot com
Get the same problem but make investigation:
$mysqli = new mysqli("localhost:3307", "my_user", "my_password",
"world");
-> got error
$mysqli = new mysqli("127.0.0.1:3307", "my_user", "my_password",
"world");
-> got error
BUT!:
$mysqli = new mysqli("127.0.0.1:3306", "my_user", "my_password",
"world");
-> change server port to default (3306).
$mysqli = new mysqli("localhost", "my_user", "my_password",
"world");
-> all works correct.
Seems that variable not parsed for $HOST_NAME and $PORT_NUMBER and
function try to connect using incorrect (not parsed) string.
[2008-08-29 11:51:21] [EMAIL PROTECTED]
I can reproduce that, assigning to mysql folks.
[2008-08-29 03:59:12] talmage dot news at gmail dot com
Upgrading to snap did not fix.
[EMAIL PROTECTED] src]# /usr/local/php/bin/php -v
PHP 5.2.7-dev (cli) (built: Aug 28 2008 20:54:37)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
[EMAIL PROTECTED] src]# /usr/local/php/bin/php -q test.php
Warning: mysqli::mysqli(): (HY000/2005): Unknown MySQL server host
'127.0.0.1:3307' (3) in /srv/php/projects/test/src/test.php on line 4
Warning: main(): Couldn't fetch mysqli in
/srv/php/projects/test/src/test.php on line 7
Warning: main(): Couldn't fetch mysqli in
/srv/php/projects/test/src/test.php on line 12
Host information:
Warning: mysqli::close(): Couldn't fetch mysqli in
/srv/php/projects/test/src/test.php on line 15
[EMAIL PROTECTED] src]#
[2008-08-28 21:13:13] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/45940
--
Edit this bug report at http://bugs.php.net/?id=45940&edit=1
#46165 [Bgs]: strcoll() does not work with UTF-8 strings on Windows
ID: 46165 Updated by: [EMAIL PROTECTED] Reported By: gehrig at ishd dot de Status: Bogus Bug Type: Strings related Operating System: win32 only PHP Version: 5.2.6 Assigned To: pajoye New Comment: strcoll is not a PHP internal functions but is part of the CRT. PHP's strcoll is only a thin wrapper around it. We have no way to change its behavior or fix it. Previous Comments: [2008-12-01 10:54:24] gehrig at ishd dot de It actually IS a PHP issue as this bug describes some software defect in a PHP core function that is intended to deliver the functionality described here: sorting an array on a locale-aware basis using available system locales. You can argue whether it's worth fixing the bug with the upcoming PHP 6 in the pipeline, but simply categorizing this as a non-PHP issue is not correct. [2008-11-30 23:05:38] [EMAIL PROTECTED] Not a php issue, use intl, mbstring or wait php6. [2008-10-29 10:11:46] [EMAIL PROTECTED] I'm not sure it is worth fixing, for many reasons. The first is to get it working on each system in a portable is a real pain (and as Derick pointed out, really not only on windows). My opinion is that all these functions should be deprecated (or strongly recommend to do not be used for anything but ascii) in favour of the new unicode APIs (6.x or partially with intl). [2008-10-29 10:05:26] [EMAIL PROTECTED] POSIX locales, don't really deal with multi byte strings like UTF8 so well, not even on unices. [2008-10-27 14:10:00] [EMAIL PROTECTED] As a windows only bug assigned to the windows port maintainer. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/46165 -- Edit this bug report at http://bugs.php.net/?id=46165&edit=1
#45799 [WFx->Asn]: imagepng() crashes on empty image
ID: 45799 Updated by: [EMAIL PROTECTED] Reported By: amelek32 at gmail dot com -Status: Wont fix +Status: Assigned Bug Type: GD related Operating System: Windows XP Pro x64 PHP Version: 5.2.6 Assigned To: pajoye New Comment: My bad, you are right! Previous Comments: [2008-12-01 11:00:46] amelek32 at gmail dot com then should return empty page.. However, it do not ;) [2008-11-30 22:52:48] [EMAIL PROTECTED] Well, after a 2nd look, the warning will remain anyway. Whether it is raised by libgd or php does not change anything > won't fix [2008-08-12 14:25:05] [EMAIL PROTECTED] > shouldn't it return warning without putting part of header to output? Hm, good point. I may add a check before calling the png function and avoid to much troubles later. I will do it for 5.3+ [2008-08-12 13:45:49] amelek32 at gmail dot com shouldn't it return warning without putting part of header to output? [2008-08-12 13:37:02] [EMAIL PROTECTED] That's libpng behaviors. A PNG palette image must have colors to be saved. By the way, warnings are not crashes. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/45799 -- Edit this bug report at http://bugs.php.net/?id=45799&edit=1
#45799 [WFx]: imagepng() crashes on empty image
ID: 45799 User updated by: amelek32 at gmail dot com Reported By: amelek32 at gmail dot com Status: Wont fix Bug Type: GD related Operating System: Windows XP Pro x64 PHP Version: 5.2.6 Assigned To: pajoye New Comment: then should return empty page.. However, it do not ;) Previous Comments: [2008-11-30 22:52:48] [EMAIL PROTECTED] Well, after a 2nd look, the warning will remain anyway. Whether it is raised by libgd or php does not change anything > won't fix [2008-08-12 14:25:05] [EMAIL PROTECTED] > shouldn't it return warning without putting part of header to output? Hm, good point. I may add a check before calling the png function and avoid to much troubles later. I will do it for 5.3+ [2008-08-12 13:45:49] amelek32 at gmail dot com shouldn't it return warning without putting part of header to output? [2008-08-12 13:37:02] [EMAIL PROTECTED] That's libpng behaviors. A PNG palette image must have colors to be saved. By the way, warnings are not crashes. [2008-08-12 13:29:36] amelek32 at gmail dot com Description: imagepng *crashes* when no color was alocated. I see no point in rendering blank images, but this functions behavior is buggy. All other functions (imagejpeg, imagegif) AND imagepng on true scale images return black image. This is most likely expected result. Instead, this function flushes some part of header and then crashes with warnings when trying to convert non existing color palette. GD Version bundled (2.0.34 compatible) Reproduce code: --- Expected result: blank black image (like other image* functions) or E_WARNING without junk. Actual result: -- PNG IHDRôôñMÉ Warning: imagepng() [function.imagepng]: gd-png: fatal libpng error: Invalid number of colors in palette in C:\usr\apache\httpd\html\draw.php on line 21 Warning: imagepng() [function.imagepng]: gd-png error: setjmp returns error condition in C:\usr\apache\httpd\html\draw.php on line 21 -- Edit this bug report at http://bugs.php.net/?id=45799&edit=1
#46165 [Bgs]: strcoll() does not work with UTF-8 strings on Windows
ID: 46165
User updated by: gehrig at ishd dot de
Reported By: gehrig at ishd dot de
Status: Bogus
Bug Type: Strings related
Operating System: win32 only
PHP Version: 5.2.6
Assigned To: pajoye
New Comment:
It actually IS a PHP issue as this bug describes some software defect
in a PHP core function that is intended to deliver the functionality
described here: sorting an array on a locale-aware basis using available
system locales.
You can argue whether it's worth fixing the bug with the upcoming PHP 6
in the pipeline, but simply categorizing this as a non-PHP issue is not
correct.
Previous Comments:
[2008-11-30 23:05:38] [EMAIL PROTECTED]
Not a php issue, use intl, mbstring or wait php6.
[2008-10-29 10:11:46] [EMAIL PROTECTED]
I'm not sure it is worth fixing, for many reasons. The first is to get
it working on each system in a portable is a real pain (and as Derick
pointed out, really not only on windows).
My opinion is that all these functions should be deprecated (or
strongly recommend to do not be used for anything but ascii) in favour
of the new unicode APIs (6.x or partially with intl).
[2008-10-29 10:05:26] [EMAIL PROTECTED]
POSIX locales, don't really deal with multi byte strings like UTF8 so
well, not even on unices.
[2008-10-27 14:10:00] [EMAIL PROTECTED]
As a windows only bug assigned to the windows port maintainer.
[2008-09-24 07:31:52] gehrig at ishd dot de
Description:
The strcoll() function for sorting comparing strings in a locale-aware
manner does not seem to work with UTF-8 encoded strings despite using
the correct Windows locale with UTF-8 codepage (65001). strcoll() always
returns 2147483647 which makes array sorting of such strings more or
less random (for example).
Running the same snippet with Windows-1252 (ISO-8859-1) encoded strings
or on a Linux machine does in fact work as expected.
Please note: for running the following reproduce code, the PHP file
must be UTF-8 encoded!
Reproduce code:
---
string(1) "a"
[1]=>
string(1) "A"
[2]=>
string(2) "ä"
[3]=>
string(2) "Ä"
[4]=>
string(1) "b"
[5]=>
string(1) "B"
[6]=>
string(1) "c"
[7]=>
string(1) "C"
[8]=>
string(1) "d"
[9]=>
string(1) "D"
[10]=>
string(1) "e"
[11]=>
string(1) "E"
[12]=>
string(1) "f"
[13]=>
string(1) "F"
[14]=>
string(1) "g"
[15]=>
string(1) "G"
[16]=>
string(1) "h"
[17]=>
string(1) "H"
[18]=>
string(1) "i"
[19]=>
string(1) "I"
[20]=>
string(1) "j"
[21]=>
string(1) "J"
[22]=>
string(1) "k"
[23]=>
string(1) "K"
[24]=>
string(1) "l"
[25]=>
string(1) "L"
[26]=>
string(1) "m"
[27]=>
string(1) "M"
[28]=>
string(1) "n"
[29]=>
string(1) "N"
[30]=>
string(1) "o"
[31]=>
string(1) "O"
[32]=>
string(2) "ö"
[33]=>
string(2) "Ö"
[34]=>
string(1) "p"
[35]=>
string(1) "P"
[36]=>
string(1) "q"
[37]=>
string(1) "Q"
[38]=>
string(1) "r"
[39]=>
string(1) "R"
[40]=>
string(1) "s"
[41]=>
string(1) "S"
[42]=>
string(2) "ß"
[43]=>
string(1) "t"
[44]=>
string(1) "T"
[45]=>
string(1) "u"
[46]=>
string(1) "U"
[47]=>
string(2) "ü"
[48]=>
string(2) "Ü"
[49]=>
string(1) "v"
[50]=>
string(1) "V"
[51]=>
string(1) "w"
[52]=>
string(1) "W"
[53]=>
string(1) "x"
[54]=>
string(1) "X"
[55]=>
string(1) "y"
[56]=>
string(1) "Y"
[57]=>
string(1) "z"
[58]=>
string(1) "Z"
}
Actual result:
--
string(20) "German_Germany.65001"
a B 2147483647
[...]
array(59) {
[0]=>
string(1) "c"
[1]=>
string(1) "B"
[2]=>
string(1) "s"
[3]=>
string(1) "C"
[4]=>
string(1) "k"
[5]=>
string(1) "D"
[6]=>
string(2) "ä"
[7]=>
string(1) "E"
[8]=>
string(1) "g"
[9]=>
string(1) "F"
[10]=>
string(1) "o"
[11]=>
string(1) "G"
[12]=>
string(1) "w"
[13]=>
string(1) "H"
[14]=>
string(1) "A"
[15]=>
string(1) "I"
[16]=>
string(1) "e"
[17]=>
string(1) "J"
[18]=>
string(1) "i"
[19]=>
string(1) "K"
[20]=>
string(1) "m"
[21]=>
string(1) "L"
[22]=>
string(1) "q"
[23]=>
string(1) "M"
[24]=>
string(1) "u"
[25]=>
string(1) "N"
[26]=>
string(1) "y"
[27]=>
string(1) "O"
[28]=>
string(2) "ü"
[29]=>
string(1) "P"
[30]=>
string(1) "b"
[31]=>
string(1) "Q"
[32]=>
string(1) "d"
[33]=>
string(1) "R"
[34]=>
string(1) "f"
[35]=>
string(1) "S"
[36]=>
string(1) "h"
[37]=>
string(1) "T"
[38]=>
string(1) "j"
[39]=>
string(1) "U"
[40]=>
string(1) "l"
[41]=>
#46724 [Opn->Bgs]: Floating number is not equal!
ID: 46724 Updated by: [EMAIL PROTECTED] Reported By: yanan at joit dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: WindowsXP PHP Version: 5.2.6 New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is, read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. Previous Comments: [2008-12-01 10:06:27] yanan at joit dot com Description: The codes below should print bool(true) .But in fact, it prints bool(false) . The same results appear when $price=10.03 or 10.04. However, when $price=10.06, it prints bool(true) . Reproduce code: --- Expected result: bool(true) Actual result: -- bool(false) -- Edit this bug report at http://bugs.php.net/?id=46724&edit=1
#46724 [NEW]: Floating number is not equal!
From: yanan at joit dot com Operating system: WindowsXP PHP version: 5.2.6 PHP Bug Type: Unknown/Other Function Bug description: Floating number is not equal! Description: The codes below should print bool(true) .But in fact, it prints bool(false) . The same results appear when $price=10.03 or 10.04. However, when $price=10.06, it prints bool(true) . Reproduce code: --- Expected result: bool(true) Actual result: -- bool(false) -- Edit bug report at http://bugs.php.net/?id=46724&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46724&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46724&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46724&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46724&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46724&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46724&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46724&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46724&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46724&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46724&r=support Expected behavior: http://bugs.php.net/fix.php?id=46724&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46724&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46724&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46724&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46724&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46724&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46724&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46724&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46724&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46724&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46724&r=mysqlcfg
#43069 [Asn->Csd]: SoapClient causes 505 HTTP Version not supported error message
ID: 43069
Updated by: [EMAIL PROTECTED]
Reported By: sebastian dot habeker at roli dot com
-Status: Assigned
+Status: Closed
Bug Type: SOAP related
Operating System: Windows 2000
PHP Version: 5.2.6
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD and PHP_5_3 (not in PHP_5_2).
Now ext/soap uses HTTP/1.1 by default, but it's possible to switch back
to HTTP/1.0 using stream context
$ctx = stream_context_create(array(
'http'=>array(
'protocol_version'=> 1.0,
)));
$soap = new SoapClient($wsdl,array("stream_context"=>$ctx));
Previous Comments:
[2008-11-28 19:27:17] [EMAIL PROTECTED]
The problem is in soap_xmlParseFile():
old_allow_url_fopen = PG(allow_url_fopen);
PG(allow_url_fopen) = 1;
ctxt = xmlCreateFileParserCtxt(filename);
PG(allow_url_fopen) = old_allow_url_fopen;
The code is trying to take advantage of the php's tcp wrapper
functionality around fopen calls so it can use xmlCreateFileParserCtxt()
with a URL. Unfortunately, the tcp wrapper functionality only supports
HTTP/1.0.
This may fixable by using xmlCreateURLParserCtxt() instead of
xmlCreateFileParserCtxt(). The documentation says it supports files and
URLs (source:
http://www.xmlsoft.org/html/libxml-parserInternals.html#xmlCreateURLParserCtxt).
I have no endpoint with which to test against this bug. Someone please
apply the following patch and test it or email me (hermanradtkePLZNOSPAM
at gmail dot com) the URL to an endpoint that only supports HTTP/1.1.
Patch: http://www.hermanradtke.com/php-43069-soap-client-http1_1.patch
[2008-10-31 06:59:07] umerfarooq dot online at gmail dot com
I am using Rest Request/ response mechanism for web services and i am
also getting this error.Is there any solution to this besides having to
upgrade or change the php version.
[2008-03-25 20:49:12] nick dot riggan at gmail dot com
I am having the same exact problem. I am running MSSQL 2005 also and
have set up an endpoint. I can load in the browser without issues but
not with the SOAP client in PHP. Has anyone solved this?
[2008-01-25 10:56:42] rob dot smith at gmx dot de
Same problem here.
OS: Windows XP
PHP: 5.2.6
[2007-11-15 11:44:00] sebastian dot habeker at roli dot com
I downloaded
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi but still
got the same problem. Is there anything else to configure, in the
php.ini or as an option in the SoapClient constructor?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/43069
--
Edit this bug report at http://bugs.php.net/?id=43069&edit=1
