Bug #61532 [Opn]: Apostrophe modifier in *printf is broken
Edit report at https://bugs.php.net/bug.php?id=61532&edit=1
ID: 61532
Updated by: johan...@php.net
Reported by:iblue at gmx dot net
Summary:Apostrophe modifier in *printf is broken
Status: Open
Type: Bug
Package:Strings related
Operating System: GNU/Linux
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
The current behaviour seems to be in line with what libc does, both on Linux
and Solaris (and gcc and suncc):
$ cat test.c
#include
void main() {
printf("%'.09i\n", 123);
}
$ gcc -otest test.c
$ ./test
00123
Previous Comments:
[2012-03-27 21:28:09] iblue at gmx dot net
Description:
When I use the apostrophe (') modifier to select a padding character in printf,
it behaves buggy, when the padding length itself is prefixed by zeroes.
Test script:
---
https://bugs.php.net/bug.php?id=61532&edit=1
Req #51285 [Com]: pgettext() and variants support for PHP
Edit report at https://bugs.php.net/bug.php?id=51285&edit=1
ID: 51285
Comment by: n dot oxyde at gmail dot com
Reported by:jani dot ollikainen at pronetko dot fi
Summary:pgettext() and variants support for PHP
Status: Open
Type: Feature/Change Request
Package:Gettext related
PHP Version:5.3.2
Block user comment: N
Private report: N
New Comment:
You don't need builtin support of pcontext() functions to use Gettext contexts.
1/ Define the functions yourself:
function pgettext($context, $message)
{
return gettext($actual_message);
}
function dpgettext($domain, $context, $message)
{
$actual_message = $context . "\04" . $message;
return dgettext($domain, $actual_message);
}
function dcpgettext($domain, $context, $message, $category)
{
$actual_message = $context . "\04" . $message;
return dcgettext($domain, $actual_message, $category);
}
function npgettext($context, $msgid1, $msgid2, $n)
{
$actual_msgid1 = $context . "\04" . $msgid1;
$actual_msgid2 = $context . "\04" . $msgid2;
return ngettext($actual_msgid1, $actual_msgid2, $n);
}
function dnpgettext($domain, $context, $msgid1, $msgid2, $n)
{
$actual_msgid1 = $context . "\04" . $msgid1;
$actual_msgid2 = $context . "\04" . $msgid2;
return dngettext($domain, $actual_msgid1, $actual_msgid2, $n);
}
function dcnpgettext(
$domain, $context, $msgid1, $msgid2, $n, $category)
{
$actual_msgid1 = $context . "\04" . $msgid1;
$actual_msgid2 = $context . "\04" . $msgid2;
return dcngettext(
$domain, $actual_msgid1, $actual_msgid2, $n, $category);
}
2/ Pass additional keywords arguments to xgettext:
xgettext \
-kpgettext:1c,2 \
-kdpgettext:2c,3 \
-kdcpgettext:2c,3 \
-knpgettext:1c,2,3 \
-kdnpgettext:2c,3,4 \
-kdcnpgettext:2c,3,4
Previous Comments:
[2010-03-12 14:56:28] jani dot ollikainen at pronetko dot fi
Description:
Newer gettext libraries provide Contexts to translate words that could
be need context based translation in other languages.
http://www.gnu.org/software/gettext/manual/gettext.html#Contexts
PHP's gettext library doesn't support those.
--
Edit this bug report at https://bugs.php.net/bug.php?id=51285&edit=1
[PHP-BUG] Bug #61700 [NEW]: FILTER_FLAG_IPV6, FILTER_FLAG_NO_PRIV_RANGE, FILTER_FLAG_NO_RES_RANGE failing
From:
Operating system:
PHP version: 5.3.10
Package: Filter related
Bug Type: Bug
Bug description:FILTER_FLAG_IPV6, FILTER_FLAG_NO_PRIV_RANGE,
FILTER_FLAG_NO_RES_RANGE failing
Description:
FILTER_FLAG_NO_PRIV_RANGE and FILTER_FLAG_NO_RES_RANGE failing in some
circumstances
Test script:
---
var_dump(filter_var(':::192.168.1.1', FILTER_VALIDATE_IP,
FILTER_FLAG_IPV4));
var_dump(filter_var(':::192.168.1.1', FILTER_VALIDATE_IP,
FILTER_FLAG_NO_PRIV_RANGE));
var_dump(filter_var('0:0:0:0:0:0:0:1', FILTER_VALIDATE_IP,
FILTER_FLAG_NO_RES_RANGE));
Expected result:
bool(true) ?
bool(false)
bool(false) as ::1 does?
Actual result:
--
bool(false)
string(18) ":::192.168.1.1"
string(15) "0:0:0:0:0:0:0:1"
--
Edit bug report at https://bugs.php.net/bug.php?id=61700&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61700&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61700&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61700&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61700&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61700&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61700&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61700&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61700&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61700&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61700&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61700&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61700&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61700&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61700&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61700&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61700&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61700&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61700&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61700&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61700&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61700&r=mysqlcfg
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1 ID: 54547 Comment by: Jeff at bobmail dot info Reported by:peter dot ritt at gmx dot net Summary:wrong equality of string numbers Status: Verified Type: Bug Package:Unknown/Other Function Operating System: linux PHP Version:5.3.6 Assigned To:dmitry Block user comment: N Private report: N New Comment: I'm confused as to why there is even a conversation around "should we fix this". The data objects are strings. Sure, PHP is "loosely typed" but shouldn't it do the comparison you tell it to do first before attempting anything else? I agree with the previous suggestion: make it a real string comparison and drop the type casting. Previous Comments: [2012-04-12 06:39:31] paj...@php.net @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. [2012-04-12 06:39:30] paj...@php.net @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. [2012-04-12 06:39:30] paj...@php.net @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. [2012-04-12 05:42:53] a at hotmail dot com @paj...@php.net How about *you* staying polite with your users by actually fixing your bugs? Can you imagine how much time is wasted worldwide as a consequence of your shortsighted "design" decisions? [2012-04-11 13:36:46] paj...@php.net @nik at naturalnet dot de Please stay polite with other developers. Please keep in mind that PHP is loosely typed, this is a root principle of PHP. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54547 -- Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1 ID: 54547 Comment by: jabakobob at gmail dot com Reported by:peter dot ritt at gmx dot net Summary:wrong equality of string numbers Status: Verified Type: Bug Package:Unknown/Other Function Operating System: linux PHP Version:5.3.6 Assigned To:dmitry Block user comment: N Private report: N New Comment: The conversion to a number is necessary because programmers don't differentiate between strings and numbers in PHP. Consider the following code: if ($_GET["a"] == $_GET["b"]) echo "a is same as b!"; The result will be the same if the query string is ?a=1&b=1 or ?a=1&b=1.0 or ? a=01&b=1 because PHP is loosely typed. Internally $_GET["a"] and $_GET["b"] are both strings, but we can't do a string comparison. If you want a string comparison, use strcmp. Previous Comments: [2012-04-12 13:31:42] Jeff at bobmail dot info I'm confused as to why there is even a conversation around "should we fix this". The data objects are strings. Sure, PHP is "loosely typed" but shouldn't it do the comparison you tell it to do first before attempting anything else? I agree with the previous suggestion: make it a real string comparison and drop the type casting. [2012-04-12 06:39:31] paj...@php.net @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. [2012-04-12 06:39:30] paj...@php.net @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. [2012-04-12 06:39:30] paj...@php.net @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. [2012-04-12 05:42:53] a at hotmail dot com @paj...@php.net How about *you* staying polite with your users by actually fixing your bugs? Can you imagine how much time is wasted worldwide as a consequence of your shortsighted "design" decisions? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54547 -- Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
[PHP-BUG] Bug #61701 [NEW]: asXML function returns string that cannot be casted as integer
From:
Operating system: Linux / ubuntu
PHP version: 5.3.10
Package: SimpleXML related
Bug Type: Bug
Bug description:asXML function returns string that cannot be casted as integer
Description:
---
>From manual page: http://www.php.net/simplexmlelement.asxml
---
I have array of arrays like
$result = array();
foreach ($wholesalers as $wholesaler) {
$result[] = array("Saldo" => $wholesaler->Available->asXML());
}
Available tag contains numeric value (integer) that should now be in
string
This simplexml generated string cannot by typecasted to integer
Test script:
---
funtion SortSaldos($array1, $array2) {
$saldo1 = $array1['Saldo'];
$saldo2 = $array2['Saldo'];
echo "type: " . gettype($saldo1) . " $saldo1 as int " .
intval($saldo1) . " vs $saldo2 " . gettype($saldo2) . " as int " .
intval($saldo2) . "";
echo "petri debug $saldo1 < $saldo2";
$saldo1 = intval($saldo1);
$saldo2 = intval($saldo2);
if ($saldo1 === $saldo2) {
echo " equal";
return 0;
}
if ($saldo1 < $saldo2) {
echo " -1 ";
return -1;
} else {
echo " 1 ";
return 1;
}
}
uasort($result, "SortSaldos");
and with the function I see my debug information on screen:
type: string 1 as int 0 vs 2 string as int 0
petri debug 1 < 2 equal
type: string 9 as int 0 vs 1 string as int 0
petri debug 9 < 1 equal
type: string 1 as int 0 vs 4 string as int 0
petri debug 1 < 4 equal
so intval is always failing for strings generated by simplexml->asXML -
function.
If I do my saldo with typecasting like this:
$result = array();
foreach ($wholesalers as $wholesaler) {
$result[] = array("Saldo" => (string) $wholesaler->Available);
}
everything works like expected
--
Edit bug report at https://bugs.php.net/bug.php?id=61701&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61701&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61701&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61701&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61701&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61701&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61701&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61701&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61701&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61701&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61701&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61701&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61701&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61701&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61701&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61701&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61701&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61701&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61701&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61701&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61701&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61701&r=mysqlcfg
Bug #54547 [Ver]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1 ID: 54547 Updated by: paj...@php.net Reported by:peter dot ritt at gmx dot net Summary:wrong equality of string numbers Status: Verified Type: Bug Package:Unknown/Other Function Operating System: linux PHP Version:5.3.6 Assigned To:dmitry Block user comment: N Private report: N New Comment: @Jeff at bobmail dot info that's what === is for (real comparisons without casting). Previous Comments: [2012-04-12 13:51:22] jabakobob at gmail dot com The conversion to a number is necessary because programmers don't differentiate between strings and numbers in PHP. Consider the following code: if ($_GET["a"] == $_GET["b"]) echo "a is same as b!"; The result will be the same if the query string is ?a=1&b=1 or ?a=1&b=1.0 or ? a=01&b=1 because PHP is loosely typed. Internally $_GET["a"] and $_GET["b"] are both strings, but we can't do a string comparison. If you want a string comparison, use strcmp. [2012-04-12 13:31:42] Jeff at bobmail dot info I'm confused as to why there is even a conversation around "should we fix this". The data objects are strings. Sure, PHP is "loosely typed" but shouldn't it do the comparison you tell it to do first before attempting anything else? I agree with the previous suggestion: make it a real string comparison and drop the type casting. [2012-04-12 06:39:31] paj...@php.net @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. [2012-04-12 06:39:30] paj...@php.net @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. [2012-04-12 06:39:30] paj...@php.net @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54547 -- Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1
ID: 54547
Comment by: ni...@php.net
Reported by:peter dot ritt at gmx dot net
Summary:wrong equality of string numbers
Status: Verified
Type: Bug
Package:Unknown/Other Function
Operating System: linux
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
@Jeff: You have to understand in PHP 1, 1.0 and "1.0" all are equivalent (in
most situations). That's by design.
E.g. GET and POST variables are always strings, even if you put numbers into
them (as per the HTTP standard). PHP obviously wants those GET/POST variables
to still be useable just like they were numbers, that's why "1" and 1 can be
used interchangeably throughout PHP.
In that context - in my eyes - this comparison also makes sense. Consider a
very similar comparison:
var_dump('0.1' == '0.1000');
What would you expect to be the output - if you remember that in PHP numeric
strings and actual numbers are interchangeable? Clearly it has to behave
exactly as if you had written:
var_dump(0.1 == 0.1000); // => bool(true)
In most cases this type of comparison is what you want and it usually works
exactly as expected.
What you see here in this issue is one of the edge cases (how often do you use
large numbers in PHP?) where it does not work well.
I hope you understand that it is not viable to remove a handy feature from PHP,
just because it fails under certain edge case conditions.
If you want to use a strict string comparison, just use ===.
Previous Comments:
[2012-04-12 13:58:53] paj...@php.net
@Jeff at bobmail dot info
that's what === is for (real comparisons without casting).
[2012-04-12 13:51:22] jabakobob at gmail dot com
The conversion to a number is necessary because programmers don't differentiate
between strings and numbers in PHP. Consider the following code:
if ($_GET["a"] == $_GET["b"]) echo "a is same as b!";
The result will be the same if the query string is ?a=1&b=1 or ?a=1&b=1.0 or ?
a=01&b=1 because PHP is loosely typed.
Internally $_GET["a"] and $_GET["b"] are both strings, but we can't do a string
comparison. If you want a string comparison, use strcmp.
[2012-04-12 13:31:42] Jeff at bobmail dot info
I'm confused as to why there is even a conversation around "should we fix this".
The data objects are strings. Sure, PHP is "loosely typed" but shouldn't it do
the comparison you tell it to do first before attempting anything else?
I agree with the previous suggestion: make it a real string comparison and drop
the type casting.
[2012-04-12 06:39:31] paj...@php.net
@a at hotmail dot com
This is not a support channel, if you need further support for the base ideas
about the loosely type nature of PHP, please ask them on one the numerous
channels.
[2012-04-12 06:39:30] paj...@php.net
@a at hotmail dot com
This is not a support channel, if you need further support for the base ideas
about the loosely type nature of PHP, please ask them on one the numerous
channels.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=54547
--
Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1
ID: 54547
Comment by: Jeff at bobmail dot info
Reported by:peter dot ritt at gmx dot net
Summary:wrong equality of string numbers
Status: Verified
Type: Bug
Package:Unknown/Other Function
Operating System: linux
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
That didn't address my comment. Why wouldn't the internal implementation check
to see if the strings are the same? When doing a comparison and the internal
data type is a string, wouldn't that be faster and most correct?
In all honesty I would prefer PHP's "loosely typed" system mimic JavaScript's
in that any type can be put anywhere but the object still keeps its type
information for situations just like this.
Previous Comments:
[2012-04-12 13:59:32] ni...@php.net
@Jeff: You have to understand in PHP 1, 1.0 and "1.0" all are equivalent (in
most situations). That's by design.
E.g. GET and POST variables are always strings, even if you put numbers into
them (as per the HTTP standard). PHP obviously wants those GET/POST variables
to still be useable just like they were numbers, that's why "1" and 1 can be
used interchangeably throughout PHP.
In that context - in my eyes - this comparison also makes sense. Consider a
very similar comparison:
var_dump('0.1' == '0.1000');
What would you expect to be the output - if you remember that in PHP numeric
strings and actual numbers are interchangeable? Clearly it has to behave
exactly as if you had written:
var_dump(0.1 == 0.1000); // => bool(true)
In most cases this type of comparison is what you want and it usually works
exactly as expected.
What you see here in this issue is one of the edge cases (how often do you use
large numbers in PHP?) where it does not work well.
I hope you understand that it is not viable to remove a handy feature from PHP,
just because it fails under certain edge case conditions.
If you want to use a strict string comparison, just use ===.
[2012-04-12 13:58:53] paj...@php.net
@Jeff at bobmail dot info
that's what === is for (real comparisons without casting).
[2012-04-12 13:51:22] jabakobob at gmail dot com
The conversion to a number is necessary because programmers don't differentiate
between strings and numbers in PHP. Consider the following code:
if ($_GET["a"] == $_GET["b"]) echo "a is same as b!";
The result will be the same if the query string is ?a=1&b=1 or ?a=1&b=1.0 or ?
a=01&b=1 because PHP is loosely typed.
Internally $_GET["a"] and $_GET["b"] are both strings, but we can't do a string
comparison. If you want a string comparison, use strcmp.
[2012-04-12 13:31:42] Jeff at bobmail dot info
I'm confused as to why there is even a conversation around "should we fix this".
The data objects are strings. Sure, PHP is "loosely typed" but shouldn't it do
the comparison you tell it to do first before attempting anything else?
I agree with the previous suggestion: make it a real string comparison and drop
the type casting.
[2012-04-12 06:39:31] paj...@php.net
@a at hotmail dot com
This is not a support channel, if you need further support for the base ideas
about the loosely type nature of PHP, please ask them on one the numerous
channels.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=54547
--
Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
Bug #60723 [Com]: error_log error time has changed to UTC ignoring default timezo
Edit report at https://bugs.php.net/bug.php?id=60723&edit=1 ID: 60723 Comment by: reggie at busicast dot com Reported by:olemarkus at gentoo dot org Summary:error_log error time has changed to UTC ignoring default timezo Status: Assigned Type: Bug Package:Date/time related Operating System: Gentoo Linux PHP Version:5.3.9 Assigned To:derick Block user comment: N Private report: N New Comment: Same: PHP 5.3.10 with Suhosin-Patch (cli) (built: Mar 14 2012 11:01:12) (DEBUG) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies with eAccelerator v0.9.6.1, Copyright (c) 2004-2010 eAccelerator, by eAccelerator Previous Comments: [2012-04-04 09:30:27] valinurovam at gmail dot com I have same problem php -v PHP 5.3.10 (cli) (built: Feb 4 2012 07:36:51) CentOS release 6.2 (Final) [2012-03-29 05:34:48] sevencat at gmail dot com Same. PHP 5.3.10 CentOS 5 [2012-03-23 13:02:03] ebert dot chris at gmail dot com Same problem for me on IIS 7, Windows 2008 Webserver, PHP 5.3.10 [2012-03-15 16:42:00] mitek17 at gmail dot com Same problem, php 5.3.9; FreeBSD 8.0 & 9.0 [2012-02-05 15:50:00] gemini dot geek at yahoo dot com hi, I am having the same issue , i am having php 5.3.9 on "CENTOS 6.2 x86_64" Deepak 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=60723 -- Edit this bug report at https://bugs.php.net/bug.php?id=60723&edit=1
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1
ID: 54547
Comment by: ni...@php.net
Reported by:peter dot ritt at gmx dot net
Summary:wrong equality of string numbers
Status: Verified
Type: Bug
Package:Unknown/Other Function
Operating System: linux
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
@Jeff Please see jabakobob's comment why doing just a string comparison can be
counterproductive. Remember: PHP is mainly used around the HTTP protocol (where
everything is a string) and MySQL (where also everything is returned as a
string). So in PHP you will often deal with numbers in strings, thus they
should be handled as such.
Previous Comments:
[2012-04-12 14:02:02] Jeff at bobmail dot info
That didn't address my comment. Why wouldn't the internal implementation check
to see if the strings are the same? When doing a comparison and the internal
data type is a string, wouldn't that be faster and most correct?
In all honesty I would prefer PHP's "loosely typed" system mimic JavaScript's
in that any type can be put anywhere but the object still keeps its type
information for situations just like this.
[2012-04-12 13:59:32] ni...@php.net
@Jeff: You have to understand in PHP 1, 1.0 and "1.0" all are equivalent (in
most situations). That's by design.
E.g. GET and POST variables are always strings, even if you put numbers into
them (as per the HTTP standard). PHP obviously wants those GET/POST variables
to still be useable just like they were numbers, that's why "1" and 1 can be
used interchangeably throughout PHP.
In that context - in my eyes - this comparison also makes sense. Consider a
very similar comparison:
var_dump('0.1' == '0.1000');
What would you expect to be the output - if you remember that in PHP numeric
strings and actual numbers are interchangeable? Clearly it has to behave
exactly as if you had written:
var_dump(0.1 == 0.1000); // => bool(true)
In most cases this type of comparison is what you want and it usually works
exactly as expected.
What you see here in this issue is one of the edge cases (how often do you use
large numbers in PHP?) where it does not work well.
I hope you understand that it is not viable to remove a handy feature from PHP,
just because it fails under certain edge case conditions.
If you want to use a strict string comparison, just use ===.
[2012-04-12 13:58:53] paj...@php.net
@Jeff at bobmail dot info
that's what === is for (real comparisons without casting).
[2012-04-12 13:51:22] jabakobob at gmail dot com
The conversion to a number is necessary because programmers don't differentiate
between strings and numbers in PHP. Consider the following code:
if ($_GET["a"] == $_GET["b"]) echo "a is same as b!";
The result will be the same if the query string is ?a=1&b=1 or ?a=1&b=1.0 or ?
a=01&b=1 because PHP is loosely typed.
Internally $_GET["a"] and $_GET["b"] are both strings, but we can't do a string
comparison. If you want a string comparison, use strcmp.
[2012-04-12 13:31:42] Jeff at bobmail dot info
I'm confused as to why there is even a conversation around "should we fix this".
The data objects are strings. Sure, PHP is "loosely typed" but shouldn't it do
the comparison you tell it to do first before attempting anything else?
I agree with the previous suggestion: make it a real string comparison and drop
the type casting.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=54547
--
Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
Bug #51800 [Com]: proc_open on Windows hangs forever
Edit report at https://bugs.php.net/bug.php?id=51800&edit=1
ID: 51800
Comment by: andremiguelcruz at msn dot com
Reported by:ph dot wolfer at googlemail dot com
Summary:proc_open on Windows hangs forever
Status: Assigned
Type: Bug
Package:Streams related
Operating System: Windows
PHP Version:*
Assigned To:ab
Block user comment: N
Private report: N
New Comment:
I hope this gets fixed soon both on 5.4 and 5.3.
Is very frustrating because I have this bug while using symfony2 with scss.
Previous Comments:
[2012-04-09 12:49:12] paj...@php.net
it seems that the issue is on main/streams.c:679
if (stream->writepos - stream->readpos < (off_t)size) {
where writepos and readpos are equals.
Anatolyi, please take a look at it.
[2012-04-08 21:21:34] s...@php.net
I could reproduce this on PHP 5.4.0 as soon as $data is longer than 4096 bytes.
With $data = str_repeat("a", 4097); in process.php it hangs forever, while with
any number until 4096 it passes.
[2012-02-19 14:37:42] nicolas dot sauveur at gmail dot com
This seems similar as https://bugs.php.net/bug.php?id=60120 .
Only partially fixed for me ( thus not fixed ) in php 5.3.9.
[2010-05-12 17:31:30] ph dot wolfer at googlemail dot com
Description:
On Windows, if you use proc_open to open another process and if you use a pipe
for STDERR, the script will hang when trying to read from STDOUT or STDERR if
the opened process outputs a lot of data.
See the example below. The called script process.php is a simple script which
writes some data to STDOUT and STDERR:
$data = str_repeat("a", 1);
fwrite(STDOUT, $data);
fwrite(STDERR, $data);
exit(0);
If called as shown below, the script will hang in the loop that reads the
STDOUT pipe. The same would happen if you would read the STDERR pipe before. If
you lower the amount of data in process.php the script will run to the end. In
my tests everything below ~2000 bytes was ok, above this value the script hang.
If you change the script below to not include the STDERR descriptor or if you
change the STDERR descriptor to a file output everything will work fine. Also
if you close the STDERR pipe before reading from STDOUT it will work. There
seems to be some deadlock.
The same script works fine on Linux.
This was tested with Windows Server 2008, IIS, PHP 5.2.13. But I have seen this
on other Windows configurations as well.
Test script:
---
array("pipe", "r"),// stdin
1 => array("pipe", "w"),// stdout
2 => array("pipe", "w") // stderr
);
$process = proc_open($cmd, $descriptors, $pipes);
if (is_resource($process))
{
fclose($pipes[0]);
while (!feof($pipes[1]))
$stdout .= fread($pipes[1], 1024);
fclose($pipes[1]);
while (!feof($pipes[2]))
$stderr .= fread($pipes[2], 1024);
fclose($pipes[2]);
$status = proc_close($process);
}
print_r(array(
"status" => $status,
"stdout" => $stdout,
"stderr" => $stderr,
));
?>
--
Edit this bug report at https://bugs.php.net/bug.php?id=51800&edit=1
Bug #61577 [Com]: php5ts.dll crashes when specific extensions are loaded
Edit report at https://bugs.php.net/bug.php?id=61577&edit=1 ID: 61577 Comment by: o6asan at yahoo dot de Reported by:uniflare at gmail dot com Summary:php5ts.dll crashes when specific extensions are loaded Status: Open Type: Bug Package:Reproducible crash Operating System: Windows7 Ultimate x86 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: I have the same issue with PHP 5.4.0 TS from windows.php.net. About 3 dll files, I've used the same configuration in php.ini for years. Until PHP 5.3.10 with Apache 2.2.22 from Apache Lounge, it worked very well. For the first time, I had this issue when I updated to PHP 5.4.0. It occurred very often at that time. I also tried Revision 323771. But, no luck. So, I quit and waited for Apache 2.4 stable from Apache Lounge. Because I thought new PHP and old Apache may not be compatible. And now, PHP 5.4.0 with Apache 2.4.2 from Apache Lounge, I have the issue again. I'm unfamiliar with PHP, but does something wrong exist in php5ts.dll ver. 5.4.0 ? The size of ver. 5.3.10 is 5,910,528 bytes and 5.4.0 is 6,109,184 bytes. >From this, we can guess some changes were made to the new file. This 24 hours, I have crashes 7 times. 3 of 7 occurred just after the message "PHP Fatal error: Maximum execution time of 30 seconds exceeded in ~". Rest of 7 has no errors in logs. And, after restarting Apache, the browser can display the requested page as if nothing happened. The php5ts.dll ver. 5.4.0 has something wrong? Previous Comments: [2012-04-12 03:28:06] uniflare at gmail dot com @pajoye at php dot net In my instance, this occurs in Apache 2.2.x and 2.4.x with PHP 5.4.0 Official Release. The 3 dll files will not work all at the same time. Try this and please tell me if you can get it to work. Note* This is a PHP crash, rather than not being able to start the webserver. There are no errors in logs that I can see apart from this event log item we have both posted. Thanks [2012-04-11 05:34:30] paj...@php.net @zane at zanezane dot net I do not think there is any crash but misconfigured install. curl, mbstring and other need DLLs to run, if the dlls are not found, it will failed. Which one did you remove or try? What says the error log? [2012-04-10 21:44:42] zane at zanezane dot net I can confirm this bug with those 3 extensions. Faulting application name: httpd.exe, version: 2.4.2.0, time stamp: 0x4f7ec1ab Faulting module name: php5ts.dll, version: 5.4.0.0, time stamp: 0x4f4e7f05 Exception code: 0xc005 Fault offset: 0x0005dd57 Faulting process id: 0x2778 Faulting application start time: 0x01cd1760e7c863da Faulting application path: D:\programs\Apache\bin\httpd.exe Faulting module path: D:\Programs\Apache\PHP\php5ts.dll Report Id: 2de7be7d-8354-11e1-9e6e-0002721fe92a * Windows 7 x64 * PHP 5.4.0 TS from windows.php.net * Apache 2.4.2 from Apache Lounge * php5apache2_4.dll-php-5.4 from Apache Lounge Disabling just one fixes the issue. [2012-03-31 00:51:16] uniflare at gmail dot com Description: Seems to be able to reproduce a crash (php5ts, apache restarts). When 3 modules are used in conjunction (if any of these modules are disabled it does not cause the problem). php_mbstring.dll php_gd2.dll php_curl.dll can produce other environment variablse as requested (php.ini/memory etc). Test script: --- N/A Any script crashes that uses the php parser engine, even blank files. Expected result: No Crash, Page Output Displayed Actual result: -- php5ts.dll crash in httpd.exe Faulting application name: httpd.exe, version: 2.2.17.0, time stamp: 0x4cbc89f4 Faulting module name: php5ts.dll, version: 5.4.0.0, time stamp: 0x4f4e7f05 Exception code: 0xc005 Fault offset: 0x0005dd17 Faulting process id: 0x1110 Faulting application start time: 0x01cd0ed73ccd2719 Faulting application path: C:\web\bin\Apache2.2\bin\httpd.exe Faulting module path: C:\web\bin\PHP5.4.0\php5ts.dll firefox reports "The page was reset". Apache restarts instantly. -- Edit this bug report at https://bugs.php.net/bug.php?id=61577&edit=1
Bug #61577 [Opn->Fbk]: php5ts.dll crashes when specific extensions are loaded
Edit report at https://bugs.php.net/bug.php?id=61577&edit=1 ID: 61577 Updated by: paj...@php.net Reported by:uniflare at gmail dot com Summary:php5ts.dll crashes when specific extensions are loaded -Status: Open +Status: Feedback Type: Bug Package:Reproducible crash Operating System: Windows7 Ultimate x86 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: @uniflare at gmail dot com Tell me which DLLs you are referring to. Without that, there is zero chance that I can even remotely going to test it. Previous Comments: [2012-04-12 15:03:49] o6asan at yahoo dot de I have the same issue with PHP 5.4.0 TS from windows.php.net. About 3 dll files, I've used the same configuration in php.ini for years. Until PHP 5.3.10 with Apache 2.2.22 from Apache Lounge, it worked very well. For the first time, I had this issue when I updated to PHP 5.4.0. It occurred very often at that time. I also tried Revision 323771. But, no luck. So, I quit and waited for Apache 2.4 stable from Apache Lounge. Because I thought new PHP and old Apache may not be compatible. And now, PHP 5.4.0 with Apache 2.4.2 from Apache Lounge, I have the issue again. I'm unfamiliar with PHP, but does something wrong exist in php5ts.dll ver. 5.4.0 ? The size of ver. 5.3.10 is 5,910,528 bytes and 5.4.0 is 6,109,184 bytes. >From this, we can guess some changes were made to the new file. This 24 hours, I have crashes 7 times. 3 of 7 occurred just after the message "PHP Fatal error: Maximum execution time of 30 seconds exceeded in ~". Rest of 7 has no errors in logs. And, after restarting Apache, the browser can display the requested page as if nothing happened. The php5ts.dll ver. 5.4.0 has something wrong? [2012-04-12 03:28:06] uniflare at gmail dot com @pajoye at php dot net In my instance, this occurs in Apache 2.2.x and 2.4.x with PHP 5.4.0 Official Release. The 3 dll files will not work all at the same time. Try this and please tell me if you can get it to work. Note* This is a PHP crash, rather than not being able to start the webserver. There are no errors in logs that I can see apart from this event log item we have both posted. Thanks [2012-04-11 05:34:30] paj...@php.net @zane at zanezane dot net I do not think there is any crash but misconfigured install. curl, mbstring and other need DLLs to run, if the dlls are not found, it will failed. Which one did you remove or try? What says the error log? [2012-04-10 21:44:42] zane at zanezane dot net I can confirm this bug with those 3 extensions. Faulting application name: httpd.exe, version: 2.4.2.0, time stamp: 0x4f7ec1ab Faulting module name: php5ts.dll, version: 5.4.0.0, time stamp: 0x4f4e7f05 Exception code: 0xc005 Fault offset: 0x0005dd57 Faulting process id: 0x2778 Faulting application start time: 0x01cd1760e7c863da Faulting application path: D:\programs\Apache\bin\httpd.exe Faulting module path: D:\Programs\Apache\PHP\php5ts.dll Report Id: 2de7be7d-8354-11e1-9e6e-0002721fe92a * Windows 7 x64 * PHP 5.4.0 TS from windows.php.net * Apache 2.4.2 from Apache Lounge * php5apache2_4.dll-php-5.4 from Apache Lounge Disabling just one fixes the issue. [2012-03-31 00:51:16] uniflare at gmail dot com Description: Seems to be able to reproduce a crash (php5ts, apache restarts). When 3 modules are used in conjunction (if any of these modules are disabled it does not cause the problem). php_mbstring.dll php_gd2.dll php_curl.dll can produce other environment variablse as requested (php.ini/memory etc). Test script: --- N/A Any script crashes that uses the php parser engine, even blank files. Expected result: No Crash, Page Output Displayed Actual result: -- php5ts.dll crash in httpd.exe Faulting application name: httpd.exe, version: 2.2.17.0, time stamp: 0x4cbc89f4 Faulting module name: php5ts.dll, version: 5.4.0.0, time stamp: 0x4f4e7f05 Exception code: 0xc005 Fault offset: 0x0005dd17 Faulting process id: 0x1110 Faulting application start time: 0x01cd0ed73ccd2719 Faulting application path: C:\web\bin\Apache2.2\bin\httpd.exe Faulting module path: C:\web\bin\PHP5.4.0\php5ts.dll firefox reports "The page was reset". Apache restarts instantly. -- Edit this bug report at https://bugs.php.net/bug.php?id=61577&edit=1
Bug #54547 [Ver]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1
ID: 54547
Updated by: jpa...@php.net
Reported by:peter dot ritt at gmx dot net
Summary:wrong equality of string numbers
Status: Verified
Type: Bug
Package:Unknown/Other Function
Operating System: linux
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
I'd like to add that strcmp() and familly are functions designed to compare
strings, as they are in C ; except that in PHP they are binary compatible, like
PHP strings are
Previous Comments:
[2012-04-12 14:17:32] ni...@php.net
@Jeff Please see jabakobob's comment why doing just a string comparison can be
counterproductive. Remember: PHP is mainly used around the HTTP protocol (where
everything is a string) and MySQL (where also everything is returned as a
string). So in PHP you will often deal with numbers in strings, thus they
should be handled as such.
[2012-04-12 14:02:02] Jeff at bobmail dot info
That didn't address my comment. Why wouldn't the internal implementation check
to see if the strings are the same? When doing a comparison and the internal
data type is a string, wouldn't that be faster and most correct?
In all honesty I would prefer PHP's "loosely typed" system mimic JavaScript's
in that any type can be put anywhere but the object still keeps its type
information for situations just like this.
[2012-04-12 13:59:32] ni...@php.net
@Jeff: You have to understand in PHP 1, 1.0 and "1.0" all are equivalent (in
most situations). That's by design.
E.g. GET and POST variables are always strings, even if you put numbers into
them (as per the HTTP standard). PHP obviously wants those GET/POST variables
to still be useable just like they were numbers, that's why "1" and 1 can be
used interchangeably throughout PHP.
In that context - in my eyes - this comparison also makes sense. Consider a
very similar comparison:
var_dump('0.1' == '0.1000');
What would you expect to be the output - if you remember that in PHP numeric
strings and actual numbers are interchangeable? Clearly it has to behave
exactly as if you had written:
var_dump(0.1 == 0.1000); // => bool(true)
In most cases this type of comparison is what you want and it usually works
exactly as expected.
What you see here in this issue is one of the edge cases (how often do you use
large numbers in PHP?) where it does not work well.
I hope you understand that it is not viable to remove a handy feature from PHP,
just because it fails under certain edge case conditions.
If you want to use a strict string comparison, just use ===.
[2012-04-12 13:58:53] paj...@php.net
@Jeff at bobmail dot info
that's what === is for (real comparisons without casting).
[2012-04-12 13:51:22] jabakobob at gmail dot com
The conversion to a number is necessary because programmers don't differentiate
between strings and numbers in PHP. Consider the following code:
if ($_GET["a"] == $_GET["b"]) echo "a is same as b!";
The result will be the same if the query string is ?a=1&b=1 or ?a=1&b=1.0 or ?
a=01&b=1 because PHP is loosely typed.
Internally $_GET["a"] and $_GET["b"] are both strings, but we can't do a string
comparison. If you want a string comparison, use strcmp.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=54547
--
Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
Req #61682 [Opn]: allow use( $var as $varCopy, &$var as $varRef) syntax for closures
Edit report at https://bugs.php.net/bug.php?id=61682&edit=1
ID: 61682
Updated by: larue...@php.net
Reported by:ninzya at inbox dot lv
Summary:allow use( $var as $varCopy, &$var as $varRef)
syntax for closures
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: Any
PHP Version:5.4.1RC1
Block user comment: N
Private report: N
New Comment:
I have made a RFC for this, but since it's a new feature, it will take time to
discuss :)
https://wiki.php.net/rfc/useas
Previous Comments:
[2012-04-09 15:43:45] ninzya at inbox dot lv
I'm sorry, in the test script a $myFn() call should follow $myFn definition:
$someLongArray =array( 1, 2, 3 );
$myFn =function() use( $someLongArray as $arrCopy, &$someLongArray as $arrRef )
{
array_push( $arrCopy, 4);
array_push( $arrRef, 5);
};
$myFn();
print_r( $someLongArray);// 1, 2, 3, 5
[2012-04-09 15:41:46] ninzya at inbox dot lv
Description:
I'd like to propose a syntax for closures that would allow to specify a name
for
the imported symbol (variable). Please see test script.
Test script:
---
$someLongArray =array( 1, 2, 3 );
$myFn =function() use( $someLongArray as $arrCopy, &$someLongArray as $arrRef )
{
array_push( $arrCopy, 4);
array_push( $arrRef, 5);
};
print_r( $someLongArray);// 1, 2, 3, 5
Expected result:
Expecting such syntax to be supported in the future.
Actual result:
--
Syntax error.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61682&edit=1
Req #32100 [Com]: Request 'finally' support for exceptions
Edit report at https://bugs.php.net/bug.php?id=32100&edit=1
ID: 32100
Comment by: matthias at die-legendaeren dot de
Reported by:ceefour at gauldong dot net
Summary:Request 'finally' support for exceptions
Status: Closed
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: *
PHP Version:5.*
Block user comment: N
Private report: N
New Comment:
"Just going to say 'Me too!'? Don't clutter the database with that please !"
But this is the right place for a "me too": to prove that a statement from 12
years ago was shortsighted and in a "works for me" way, developers (as
customers)
who disagree have to group behind their request.
Previous Comments:
[2012-04-11 21:21:33] gudjonj at gmail dot com
+1 for finally in PHP
[2012-04-11 08:34:13] ravilov at gmail dot com
My two cents...
Here's an example of emulating "finally" in PHP without needing to duplicate
code.
$_ex = null;
AllocateSomeResource();
try {
DoSomeProcessing();
} catch (Exception $ex) {
$_ex = $ex;
}
DeallocateSomeResource();
if ($_ex != null) {
throw $_ex;
}
That said, I completely agree any current workaround/emulation/"solution" is
nothing but cumbersome and bug-prone, and that we shouldn't have to come up
with such creative ways to overcome what seems like a language design flaw. PHP
is a tool, it is supposed to work *with* us, not *against* us.
[2012-04-03 13:08:00] andrew dot feller at gmail dot com
The demand for "finally" is a symptom of PHP not officially and explicitly
addressing supported solutions to managing resources. I cannot find anything
within PHP documentation to address this:
http://www.php.net/manual/en/language.oop5.decon.php
http://www.php.net/manual/en/faq.misc.php
So I recommend to move beyond inclusion of finalizers and start with educating
constituents because there is an opportunity to resolve this and hopefully
improve quality of work done by developers
[2012-01-02 12:02:49] frederic dot hardy at mageekbox dot net
I'm not sure that this place is the right place to discuss about that.
Since the last year, PHP has a process to discuss technical point, aka RFC
(https://wiki.php.net/rfc).
So, if "finally" must be included in PHP, just write the relative RFC and
discuss
it on internals.
Sure that time has changed, because PHP's users are more power now than in the
past !
[2011-12-08 17:40:44] antoninweb at gmail dot com
I don't understand how this is not included when PHP supports try...catch. It
just
doesn't makes sense and it's annoying because you have to find ways around it
contantly.
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=32100
--
Edit this bug report at https://bugs.php.net/bug.php?id=32100&edit=1
Bug #61518 [Com]: skip on windows - ext/standard/tests/streams/bug60106.phpt
Edit report at https://bugs.php.net/bug.php?id=61518&edit=1 ID: 61518 Comment by: reeze dot xia at gmail dot com Reported by:mattfic...@php.net Summary:skip on windows - ext/standard/tests/streams/bug60106.phpt Status: Closed Type: Bug Package:Testing related Operating System: Windows PHP Version:5.3.10 Assigned To:ab Block user comment: N Private report: N New Comment: @mattficken @ab Indeed bugfix #60106 failed too, this is because php's default log_errors_max_len=1024, but trying to output more than that. error log have been trancated. so test failed. I've sent a pull request https://github.com/php/php-src/pull/55. Thanks. Previous Comments: [2012-04-02 23:09:28] mattfic...@php.net For me, patch skips this test on Windows (which its supposed to). However, on Linux, with PHP5.3.11rc1, the test fails (with or without the patch) because the socket name printed in the warning messages doesn't have 4096 'a' characters like the test expects. [2012-03-29 04:23:43] a...@php.net Automatic comment on behalf of ab Revision: http://git.php.net/?p=php-src.git;a=commit;h=da85d5b4a00943a267db910299bdaee04c081c25 Log: Fix bug #61518 skip on windows, fix on linux - ext/standard/tests/streams/bug60106.phpt [2012-03-27 17:30:50] a...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2012-03-27 17:26:06] a...@php.net Automatic comment on behalf of ab Revision: http://git.php.net/?p=php-src.git;a=commit;h=da85d5b4a00943a267db910299bdaee04c081c25 Log: Fix bug #61518 skip on windows, fix on linux - ext/standard/tests/streams/bug60106.phpt [2012-03-27 08:58:09] a...@php.net extended the patch for the test to pass on linux - fixed a's count 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=61518 -- Edit this bug report at https://bugs.php.net/bug.php?id=61518&edit=1
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1
ID: 54547
Comment by: yless42 at hotmail dot com
Reported by:peter dot ritt at gmx dot net
Summary:wrong equality of string numbers
Status: Verified
Type: Bug
Package:Unknown/Other Function
Operating System: linux
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
Wouldn't it make the most sense to compare the strings as string (and thus pass
in the original case), then fall back on other comparison methods when they
don't match? I admit I don't have test cases but it seems that this would be
backwards compatible in most cases (as you will eventually compare numerically)
and fix the given issue.
Unless there are cases which rely on the two same strings failing to compare as
equal.
Previous Comments:
[2012-04-12 15:20:45] jpa...@php.net
I'd like to add that strcmp() and familly are functions designed to compare
strings, as they are in C ; except that in PHP they are binary compatible, like
PHP strings are
[2012-04-12 14:17:32] ni...@php.net
@Jeff Please see jabakobob's comment why doing just a string comparison can be
counterproductive. Remember: PHP is mainly used around the HTTP protocol (where
everything is a string) and MySQL (where also everything is returned as a
string). So in PHP you will often deal with numbers in strings, thus they
should be handled as such.
[2012-04-12 14:02:02] Jeff at bobmail dot info
That didn't address my comment. Why wouldn't the internal implementation check
to see if the strings are the same? When doing a comparison and the internal
data type is a string, wouldn't that be faster and most correct?
In all honesty I would prefer PHP's "loosely typed" system mimic JavaScript's
in that any type can be put anywhere but the object still keeps its type
information for situations just like this.
[2012-04-12 13:59:32] ni...@php.net
@Jeff: You have to understand in PHP 1, 1.0 and "1.0" all are equivalent (in
most situations). That's by design.
E.g. GET and POST variables are always strings, even if you put numbers into
them (as per the HTTP standard). PHP obviously wants those GET/POST variables
to still be useable just like they were numbers, that's why "1" and 1 can be
used interchangeably throughout PHP.
In that context - in my eyes - this comparison also makes sense. Consider a
very similar comparison:
var_dump('0.1' == '0.1000');
What would you expect to be the output - if you remember that in PHP numeric
strings and actual numbers are interchangeable? Clearly it has to behave
exactly as if you had written:
var_dump(0.1 == 0.1000); // => bool(true)
In most cases this type of comparison is what you want and it usually works
exactly as expected.
What you see here in this issue is one of the edge cases (how often do you use
large numbers in PHP?) where it does not work well.
I hope you understand that it is not viable to remove a handy feature from PHP,
just because it fails under certain edge case conditions.
If you want to use a strict string comparison, just use ===.
[2012-04-12 13:58:53] paj...@php.net
@Jeff at bobmail dot info
that's what === is for (real comparisons without casting).
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=54547
--
Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1
ID: 54547
Comment by: jacob at fakku dot net
Reported by:peter dot ritt at gmx dot net
Summary:wrong equality of string numbers
Status: Verified
Type: Bug
Package:Unknown/Other Function
Operating System: linux
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
I'm just gonna paste in that PHP Sadness article to show why this is such a big
issue.
According to php language.operators.comparison, the type-coercing comparison
operators will coerce both operands to floats if they both look like numbers,
even if they are both already strings:
If you compare a number with a string or the comparison involves numerical
strings, then each string is converted to a number and the comparison performed
numerically.
This can become especially important in situations where the developer chooses
to use == to compare two values which will always be strings. For example,
consider a simple password checker:
if (md5($password) == $hash) {
print "Allowed!\n";
}
Assume that the $hash is loaded from a known safe string value from a database
and contains a real MD5 hash. Now, suppose the $password is "ximaz", which has
an all-numeric hex-encoded MD5 hash of "61529519452809720693702583126814". When
PHP does the comparison, it will print "Allowed!" for any password which
matches
even the first half of the hash:
$ php -r 'var_dump("61529519452809720693702583126814" ==
"6152951945280972");'
bool(true)
The solution, of course, is "never use type-coercing comparison operators" -
but
this remains an easily-overlooked bug factory for beginning and even
intermediate developers. Some languages solve this situation by having two
separate sets of comparison operators for numeric or string comparisons so that
the developer can be explicit in their intent without needing to manually cast
their arguments.
Previous Comments:
[2012-04-12 15:55:26] yless42 at hotmail dot com
Wouldn't it make the most sense to compare the strings as string (and thus pass
in the original case), then fall back on other comparison methods when they
don't match? I admit I don't have test cases but it seems that this would be
backwards compatible in most cases (as you will eventually compare numerically)
and fix the given issue.
Unless there are cases which rely on the two same strings failing to compare as
equal.
[2012-04-12 15:20:45] jpa...@php.net
I'd like to add that strcmp() and familly are functions designed to compare
strings, as they are in C ; except that in PHP they are binary compatible, like
PHP strings are
[2012-04-12 14:17:32] ni...@php.net
@Jeff Please see jabakobob's comment why doing just a string comparison can be
counterproductive. Remember: PHP is mainly used around the HTTP protocol (where
everything is a string) and MySQL (where also everything is returned as a
string). So in PHP you will often deal with numbers in strings, thus they
should be handled as such.
[2012-04-12 14:02:02] Jeff at bobmail dot info
That didn't address my comment. Why wouldn't the internal implementation check
to see if the strings are the same? When doing a comparison and the internal
data type is a string, wouldn't that be faster and most correct?
In all honesty I would prefer PHP's "loosely typed" system mimic JavaScript's
in that any type can be put anywhere but the object still keeps its type
information for situations just like this.
[2012-04-12 13:59:32] ni...@php.net
@Jeff: You have to understand in PHP 1, 1.0 and "1.0" all are equivalent (in
most situations). That's by design.
E.g. GET and POST variables are always strings, even if you put numbers into
them (as per the HTTP standard). PHP obviously wants those GET/POST variables
to still be useable just like they were numbers, that's why "1" and 1 can be
used interchangeably throughout PHP.
In that context - in my eyes - this comparison also makes sense. Consider a
very similar comparison:
var_dump('0.1' == '0.1000');
What would you expect to be the output - if you remember that in PHP numeric
strings and actual numbers are interchangeable? Clearly it has to behave
exactly as if you had written:
var_dump(0.1 == 0.1000); // => bool(true)
In most cases this type of comparison is what you want and it usually works
exactly as expected.
What you see here in this issue is one of the edge cases (how often do you use
large numbers in PHP?) where it do
Bug #54547 [Ver]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1
ID: 54547
Updated by: ras...@php.net
Reported by:peter dot ritt at gmx dot net
Summary:wrong equality of string numbers
Status: Verified
Type: Bug
Package:Unknown/Other Function
Operating System: linux
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
@jacob PHP has two sets of comparison operators as well. == and ===
They aren't numeric and string, they are loose and strict. In the majority of
cases when dealing with HTTP requests and database results, which is what PHP
deals with most, the loose comparison makes life easiest on the developer.
In your case when comparison huge numeric strings that won't fit in any numeric
type, a strict comparison is needed:
$ php -r 'var_dump("61529519452809720693702583126814" ===
"6152951945280972");'
bool(false)
(and hopefully you aren't actually using md5 for password hashing)
Previous Comments:
[2012-04-12 16:04:03] jacob at fakku dot net
I'm just gonna paste in that PHP Sadness article to show why this is such a big
issue.
According to php language.operators.comparison, the type-coercing comparison
operators will coerce both operands to floats if they both look like numbers,
even if they are both already strings:
If you compare a number with a string or the comparison involves numerical
strings, then each string is converted to a number and the comparison performed
numerically.
This can become especially important in situations where the developer chooses
to use == to compare two values which will always be strings. For example,
consider a simple password checker:
if (md5($password) == $hash) {
print "Allowed!\n";
}
Assume that the $hash is loaded from a known safe string value from a database
and contains a real MD5 hash. Now, suppose the $password is "ximaz", which has
an all-numeric hex-encoded MD5 hash of "61529519452809720693702583126814". When
PHP does the comparison, it will print "Allowed!" for any password which
matches
even the first half of the hash:
$ php -r 'var_dump("61529519452809720693702583126814" ==
"6152951945280972");'
bool(true)
The solution, of course, is "never use type-coercing comparison operators" -
but
this remains an easily-overlooked bug factory for beginning and even
intermediate developers. Some languages solve this situation by having two
separate sets of comparison operators for numeric or string comparisons so that
the developer can be explicit in their intent without needing to manually cast
their arguments.
[2012-04-12 15:55:26] yless42 at hotmail dot com
Wouldn't it make the most sense to compare the strings as string (and thus pass
in the original case), then fall back on other comparison methods when they
don't match? I admit I don't have test cases but it seems that this would be
backwards compatible in most cases (as you will eventually compare numerically)
and fix the given issue.
Unless there are cases which rely on the two same strings failing to compare as
equal.
[2012-04-12 15:20:45] jpa...@php.net
I'd like to add that strcmp() and familly are functions designed to compare
strings, as they are in C ; except that in PHP they are binary compatible, like
PHP strings are
[2012-04-12 14:17:32] ni...@php.net
@Jeff Please see jabakobob's comment why doing just a string comparison can be
counterproductive. Remember: PHP is mainly used around the HTTP protocol (where
everything is a string) and MySQL (where also everything is returned as a
string). So in PHP you will often deal with numbers in strings, thus they
should be handled as such.
[2012-04-12 14:02:02] Jeff at bobmail dot info
That didn't address my comment. Why wouldn't the internal implementation check
to see if the strings are the same? When doing a comparison and the internal
data type is a string, wouldn't that be faster and most correct?
In all honesty I would prefer PHP's "loosely typed" system mimic JavaScript's
in that any type can be put anywhere but the object still keeps its type
information for situations just like this.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=54547
--
Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
Bug #61577 [Com]: php5ts.dll crashes when specific extensions are loaded
Edit report at https://bugs.php.net/bug.php?id=61577&edit=1 ID: 61577 Comment by: jmquarck at gmail dot com Reported by:uniflare at gmail dot com Summary:php5ts.dll crashes when specific extensions are loaded Status: Feedback Type: Bug Package:Reproducible crash Operating System: Windows7 Ultimate x86 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Using Windows 7 Ultimate 64 bits with PHP 5.4 and Apache 2.4 or Apache 2.2 http://localhost OK http://localhost/phpinfo.phpcrashes and changes url to www.localhost.com/phpinfo.php It happens even if mbstring, curl and g2 extensions are disabled. Previous Comments: [2012-04-12 15:07:13] paj...@php.net @uniflare at gmail dot com Tell me which DLLs you are referring to. Without that, there is zero chance that I can even remotely going to test it. [2012-04-12 15:03:49] o6asan at yahoo dot de I have the same issue with PHP 5.4.0 TS from windows.php.net. About 3 dll files, I've used the same configuration in php.ini for years. Until PHP 5.3.10 with Apache 2.2.22 from Apache Lounge, it worked very well. For the first time, I had this issue when I updated to PHP 5.4.0. It occurred very often at that time. I also tried Revision 323771. But, no luck. So, I quit and waited for Apache 2.4 stable from Apache Lounge. Because I thought new PHP and old Apache may not be compatible. And now, PHP 5.4.0 with Apache 2.4.2 from Apache Lounge, I have the issue again. I'm unfamiliar with PHP, but does something wrong exist in php5ts.dll ver. 5.4.0 ? The size of ver. 5.3.10 is 5,910,528 bytes and 5.4.0 is 6,109,184 bytes. >From this, we can guess some changes were made to the new file. This 24 hours, I have crashes 7 times. 3 of 7 occurred just after the message "PHP Fatal error: Maximum execution time of 30 seconds exceeded in ~". Rest of 7 has no errors in logs. And, after restarting Apache, the browser can display the requested page as if nothing happened. The php5ts.dll ver. 5.4.0 has something wrong? [2012-04-12 03:28:06] uniflare at gmail dot com @pajoye at php dot net In my instance, this occurs in Apache 2.2.x and 2.4.x with PHP 5.4.0 Official Release. The 3 dll files will not work all at the same time. Try this and please tell me if you can get it to work. Note* This is a PHP crash, rather than not being able to start the webserver. There are no errors in logs that I can see apart from this event log item we have both posted. Thanks [2012-04-11 05:34:30] paj...@php.net @zane at zanezane dot net I do not think there is any crash but misconfigured install. curl, mbstring and other need DLLs to run, if the dlls are not found, it will failed. Which one did you remove or try? What says the error log? [2012-04-10 21:44:42] zane at zanezane dot net I can confirm this bug with those 3 extensions. Faulting application name: httpd.exe, version: 2.4.2.0, time stamp: 0x4f7ec1ab Faulting module name: php5ts.dll, version: 5.4.0.0, time stamp: 0x4f4e7f05 Exception code: 0xc005 Fault offset: 0x0005dd57 Faulting process id: 0x2778 Faulting application start time: 0x01cd1760e7c863da Faulting application path: D:\programs\Apache\bin\httpd.exe Faulting module path: D:\Programs\Apache\PHP\php5ts.dll Report Id: 2de7be7d-8354-11e1-9e6e-0002721fe92a * Windows 7 x64 * PHP 5.4.0 TS from windows.php.net * Apache 2.4.2 from Apache Lounge * php5apache2_4.dll-php-5.4 from Apache Lounge Disabling just one fixes the issue. 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=61577 -- Edit this bug report at https://bugs.php.net/bug.php?id=61577&edit=1
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1
ID: 54547
Comment by: jacob at fakku dot net
Reported by:peter dot ritt at gmx dot net
Summary:wrong equality of string numbers
Status: Verified
Type: Bug
Package:Unknown/Other Function
Operating System: linux
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
@rasmus
I just wanted to point out the issue mentioned in that article and how I felt
it
applied to this situation.
At least to me, it seems to me that it's a big deal when '9223372036854775807'
==
'9223372036854775808' returns true, even if it's an edge case. But you're right
about just using ===, which I will do if I ever run into this situation. After
doing a bit more research I can understand why it is the way it is and I was
probably too hasty to jump into this thread.
Previous Comments:
[2012-04-12 16:53:54] ras...@php.net
@jacob PHP has two sets of comparison operators as well. == and ===
They aren't numeric and string, they are loose and strict. In the majority of
cases when dealing with HTTP requests and database results, which is what PHP
deals with most, the loose comparison makes life easiest on the developer.
In your case when comparison huge numeric strings that won't fit in any numeric
type, a strict comparison is needed:
$ php -r 'var_dump("61529519452809720693702583126814" ===
"6152951945280972");'
bool(false)
(and hopefully you aren't actually using md5 for password hashing)
[2012-04-12 16:04:03] jacob at fakku dot net
I'm just gonna paste in that PHP Sadness article to show why this is such a big
issue.
According to php language.operators.comparison, the type-coercing comparison
operators will coerce both operands to floats if they both look like numbers,
even if they are both already strings:
If you compare a number with a string or the comparison involves numerical
strings, then each string is converted to a number and the comparison performed
numerically.
This can become especially important in situations where the developer chooses
to use == to compare two values which will always be strings. For example,
consider a simple password checker:
if (md5($password) == $hash) {
print "Allowed!\n";
}
Assume that the $hash is loaded from a known safe string value from a database
and contains a real MD5 hash. Now, suppose the $password is "ximaz", which has
an all-numeric hex-encoded MD5 hash of "61529519452809720693702583126814". When
PHP does the comparison, it will print "Allowed!" for any password which
matches
even the first half of the hash:
$ php -r 'var_dump("61529519452809720693702583126814" ==
"6152951945280972");'
bool(true)
The solution, of course, is "never use type-coercing comparison operators" -
but
this remains an easily-overlooked bug factory for beginning and even
intermediate developers. Some languages solve this situation by having two
separate sets of comparison operators for numeric or string comparisons so that
the developer can be explicit in their intent without needing to manually cast
their arguments.
[2012-04-12 15:55:26] yless42 at hotmail dot com
Wouldn't it make the most sense to compare the strings as string (and thus pass
in the original case), then fall back on other comparison methods when they
don't match? I admit I don't have test cases but it seems that this would be
backwards compatible in most cases (as you will eventually compare numerically)
and fix the given issue.
Unless there are cases which rely on the two same strings failing to compare as
equal.
[2012-04-12 15:20:45] jpa...@php.net
I'd like to add that strcmp() and familly are functions designed to compare
strings, as they are in C ; except that in PHP they are binary compatible, like
PHP strings are
[2012-04-12 14:17:32] ni...@php.net
@Jeff Please see jabakobob's comment why doing just a string comparison can be
counterproductive. Remember: PHP is mainly used around the HTTP protocol (where
everything is a string) and MySQL (where also everything is returned as a
string). So in PHP you will often deal with numbers in strings, thus they
should be handled as such.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=54547
--
Edit this bug report at https://bugs.php.net/bug.php?id=
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1
ID: 54547
Comment by: riel at surriel dot com
Reported by:peter dot ritt at gmx dot net
Summary:wrong equality of string numbers
Status: Verified
Type: Bug
Package:Unknown/Other Function
Operating System: linux
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
Conversion of numeric-looking strings to numbers does not have to be a problem,
as long as the code in the back end uses arbitrary-precision math. This is
slower than comparing a type that fits in a CPU register, but once you have
already spent the time to do an automatic type conversion, that really does not
matter.
When it comes to an operator like ==, every digit matters. Having == return
false when two items are different violates the principle of least surprise.
Previous Comments:
[2012-04-12 17:03:32] jacob at fakku dot net
@rasmus
I just wanted to point out the issue mentioned in that article and how I felt
it
applied to this situation.
At least to me, it seems to me that it's a big deal when '9223372036854775807'
==
'9223372036854775808' returns true, even if it's an edge case. But you're right
about just using ===, which I will do if I ever run into this situation. After
doing a bit more research I can understand why it is the way it is and I was
probably too hasty to jump into this thread.
[2012-04-12 16:53:54] ras...@php.net
@jacob PHP has two sets of comparison operators as well. == and ===
They aren't numeric and string, they are loose and strict. In the majority of
cases when dealing with HTTP requests and database results, which is what PHP
deals with most, the loose comparison makes life easiest on the developer.
In your case when comparison huge numeric strings that won't fit in any numeric
type, a strict comparison is needed:
$ php -r 'var_dump("61529519452809720693702583126814" ===
"6152951945280972");'
bool(false)
(and hopefully you aren't actually using md5 for password hashing)
[2012-04-12 16:04:03] jacob at fakku dot net
I'm just gonna paste in that PHP Sadness article to show why this is such a big
issue.
According to php language.operators.comparison, the type-coercing comparison
operators will coerce both operands to floats if they both look like numbers,
even if they are both already strings:
If you compare a number with a string or the comparison involves numerical
strings, then each string is converted to a number and the comparison performed
numerically.
This can become especially important in situations where the developer chooses
to use == to compare two values which will always be strings. For example,
consider a simple password checker:
if (md5($password) == $hash) {
print "Allowed!\n";
}
Assume that the $hash is loaded from a known safe string value from a database
and contains a real MD5 hash. Now, suppose the $password is "ximaz", which has
an all-numeric hex-encoded MD5 hash of "61529519452809720693702583126814". When
PHP does the comparison, it will print "Allowed!" for any password which
matches
even the first half of the hash:
$ php -r 'var_dump("61529519452809720693702583126814" ==
"6152951945280972");'
bool(true)
The solution, of course, is "never use type-coercing comparison operators" -
but
this remains an easily-overlooked bug factory for beginning and even
intermediate developers. Some languages solve this situation by having two
separate sets of comparison operators for numeric or string comparisons so that
the developer can be explicit in their intent without needing to manually cast
their arguments.
[2012-04-12 15:55:26] yless42 at hotmail dot com
Wouldn't it make the most sense to compare the strings as string (and thus pass
in the original case), then fall back on other comparison methods when they
don't match? I admit I don't have test cases but it seems that this would be
backwards compatible in most cases (as you will eventually compare numerically)
and fix the given issue.
Unless there are cases which rely on the two same strings failing to compare as
equal.
[2012-04-12 15:20:45] jpa...@php.net
I'd like to add that strcmp() and familly are functions designed to compare
strings, as they are in C ; except that in PHP they are binary compatible, like
PHP strings are
The remainder of the comments for this report are too long. To view
the rest of the co
Bug #61577 [Fbk->Opn]: php5ts.dll crashes when specific extensions are loaded
Edit report at https://bugs.php.net/bug.php?id=61577&edit=1 ID: 61577 User updated by:uniflare at gmail dot com Reported by:uniflare at gmail dot com Summary:php5ts.dll crashes when specific extensions are loaded -Status: Feedback +Status: Open Type: Bug Package:Reproducible crash Operating System: Windows7 Ultimate x86 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: @pajoye at php dot net Are you unable to read the original bug report or something, the dll files in question were mentioned in the description... This should be looked into, it means you cannot use mbstring, curl and GD2 at the same time, which is not good at all. They all serve a very useful purpose. There is obviously some compatibility issue with these dll's. If you cannot read the original bug report, then here; php_mbstring.dll php_gd2.dll php_curl.dll -- This is using a default setup as explained above on a system more than capable. And trust me, I am by far no beginner in using PHP, compiling my own versions with custom extensions etc. Trust me when i say, this should not be happening. PHP5.3.10 has NO problems using all 3 extensions. only PHP 5.4.0. Thanks. Previous Comments: [2012-04-12 16:55:54] jmquarck at gmail dot com Using Windows 7 Ultimate 64 bits with PHP 5.4 and Apache 2.4 or Apache 2.2 http://localhost OK http://localhost/phpinfo.phpcrashes and changes url to www.localhost.com/phpinfo.php It happens even if mbstring, curl and g2 extensions are disabled. [2012-04-12 15:07:13] paj...@php.net @uniflare at gmail dot com Tell me which DLLs you are referring to. Without that, there is zero chance that I can even remotely going to test it. [2012-04-12 15:03:49] o6asan at yahoo dot de I have the same issue with PHP 5.4.0 TS from windows.php.net. About 3 dll files, I've used the same configuration in php.ini for years. Until PHP 5.3.10 with Apache 2.2.22 from Apache Lounge, it worked very well. For the first time, I had this issue when I updated to PHP 5.4.0. It occurred very often at that time. I also tried Revision 323771. But, no luck. So, I quit and waited for Apache 2.4 stable from Apache Lounge. Because I thought new PHP and old Apache may not be compatible. And now, PHP 5.4.0 with Apache 2.4.2 from Apache Lounge, I have the issue again. I'm unfamiliar with PHP, but does something wrong exist in php5ts.dll ver. 5.4.0 ? The size of ver. 5.3.10 is 5,910,528 bytes and 5.4.0 is 6,109,184 bytes. >From this, we can guess some changes were made to the new file. This 24 hours, I have crashes 7 times. 3 of 7 occurred just after the message "PHP Fatal error: Maximum execution time of 30 seconds exceeded in ~". Rest of 7 has no errors in logs. And, after restarting Apache, the browser can display the requested page as if nothing happened. The php5ts.dll ver. 5.4.0 has something wrong? [2012-04-12 03:28:06] uniflare at gmail dot com @pajoye at php dot net In my instance, this occurs in Apache 2.2.x and 2.4.x with PHP 5.4.0 Official Release. The 3 dll files will not work all at the same time. Try this and please tell me if you can get it to work. Note* This is a PHP crash, rather than not being able to start the webserver. There are no errors in logs that I can see apart from this event log item we have both posted. Thanks [2012-04-11 05:34:30] paj...@php.net @zane at zanezane dot net I do not think there is any crash but misconfigured install. curl, mbstring and other need DLLs to run, if the dlls are not found, it will failed. Which one did you remove or try? What says the error log? 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=61577 -- Edit this bug report at https://bugs.php.net/bug.php?id=61577&edit=1
Bug #61577 [Opn->Asn]: php5ts.dll crashes when specific extensions are loaded
Edit report at https://bugs.php.net/bug.php?id=61577&edit=1 ID: 61577 Updated by: paj...@php.net Reported by:uniflare at gmail dot com Summary:php5ts.dll crashes when specific extensions are loaded -Status: Open +Status: Assigned Type: Bug Package:Reproducible crash Operating System: Windows7 Ultimate x86 PHP Version:5.4.0 -Assigned To: +Assigned To:mattficken Block user comment: N Private report: N New Comment: You said "I removed some and it works", or something along this line... @matt, please follow that further. As in, load this 3 DLLs with the given versions and see if it works in the same configuration. Previous Comments: [2012-04-12 17:20:10] uniflare at gmail dot com @pajoye at php dot net Are you unable to read the original bug report or something, the dll files in question were mentioned in the description... This should be looked into, it means you cannot use mbstring, curl and GD2 at the same time, which is not good at all. They all serve a very useful purpose. There is obviously some compatibility issue with these dll's. If you cannot read the original bug report, then here; php_mbstring.dll php_gd2.dll php_curl.dll -- This is using a default setup as explained above on a system more than capable. And trust me, I am by far no beginner in using PHP, compiling my own versions with custom extensions etc. Trust me when i say, this should not be happening. PHP5.3.10 has NO problems using all 3 extensions. only PHP 5.4.0. Thanks. [2012-04-12 16:55:54] jmquarck at gmail dot com Using Windows 7 Ultimate 64 bits with PHP 5.4 and Apache 2.4 or Apache 2.2 http://localhost OK http://localhost/phpinfo.phpcrashes and changes url to www.localhost.com/phpinfo.php It happens even if mbstring, curl and g2 extensions are disabled. [2012-04-12 15:07:13] paj...@php.net @uniflare at gmail dot com Tell me which DLLs you are referring to. Without that, there is zero chance that I can even remotely going to test it. [2012-04-12 15:03:49] o6asan at yahoo dot de I have the same issue with PHP 5.4.0 TS from windows.php.net. About 3 dll files, I've used the same configuration in php.ini for years. Until PHP 5.3.10 with Apache 2.2.22 from Apache Lounge, it worked very well. For the first time, I had this issue when I updated to PHP 5.4.0. It occurred very often at that time. I also tried Revision 323771. But, no luck. So, I quit and waited for Apache 2.4 stable from Apache Lounge. Because I thought new PHP and old Apache may not be compatible. And now, PHP 5.4.0 with Apache 2.4.2 from Apache Lounge, I have the issue again. I'm unfamiliar with PHP, but does something wrong exist in php5ts.dll ver. 5.4.0 ? The size of ver. 5.3.10 is 5,910,528 bytes and 5.4.0 is 6,109,184 bytes. >From this, we can guess some changes were made to the new file. This 24 hours, I have crashes 7 times. 3 of 7 occurred just after the message "PHP Fatal error: Maximum execution time of 30 seconds exceeded in ~". Rest of 7 has no errors in logs. And, after restarting Apache, the browser can display the requested page as if nothing happened. The php5ts.dll ver. 5.4.0 has something wrong? [2012-04-12 03:28:06] uniflare at gmail dot com @pajoye at php dot net In my instance, this occurs in Apache 2.2.x and 2.4.x with PHP 5.4.0 Official Release. The 3 dll files will not work all at the same time. Try this and please tell me if you can get it to work. Note* This is a PHP crash, rather than not being able to start the webserver. There are no errors in logs that I can see apart from this event log item we have both posted. Thanks 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=61577 -- Edit this bug report at https://bugs.php.net/bug.php?id=61577&edit=1
[PHP-BUG] Req #61703 [NEW]: sort-array
From: Operating system: pc PHP version: 5.3.10 Package: Arrays related Bug Type: Feature/Change Request Bug description:sort-array Description: --- >From manual page: http://www.php.net/function.sort --- I wanted to request a feature to the sort function. I noticed it did not have optional parameter to retain the keys of the array. Instead it re-writes them. why not add an optional 3rd boolean paramter to decide to retain keys in the original array or not? -- Edit bug report at https://bugs.php.net/bug.php?id=61703&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61703&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61703&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61703&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61703&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61703&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61703&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61703&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61703&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61703&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61703&r=support Expected behavior: https://bugs.php.net/fix.php?id=61703&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61703&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61703&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61703&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61703&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61703&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61703&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61703&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61703&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61703&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61703&r=mysqlcfg
Req #61703 [Com]: sort-array
Edit report at https://bugs.php.net/bug.php?id=61703&edit=1 ID: 61703 Comment by: admin at sinfocol dot org Reported by:sia88 at utexas dot edu Summary:sort-array Status: Open Type: Feature/Change Request Package:Arrays related Operating System: pc PHP Version:5.3.10 Block user comment: N Private report: N New Comment: The feature is already implemented in another function called asort. Previous Comments: [2012-04-12 19:00:14] sia88 at utexas dot edu Description: --- >From manual page: http://www.php.net/function.sort --- I wanted to request a feature to the sort function. I noticed it did not have optional parameter to retain the keys of the array. Instead it re-writes them. why not add an optional 3rd boolean paramter to decide to retain keys in the original array or not? -- Edit this bug report at https://bugs.php.net/bug.php?id=61703&edit=1
Bug #61597 [Com]: SimpleXML drops attributes for tags with both attributes and text
Edit report at https://bugs.php.net/bug.php?id=61597&edit=1
ID: 61597
Comment by: jplyon dot csu at gmail dot com
Reported by:drgroove at gmail dot com
Summary:SimpleXML drops attributes for tags with both
attributes and text
Status: Feedback
Type: Bug
Package:SimpleXML related
Operating System: Mac OS X
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
another test:
$xml = <<<'EOX'
corn
EOX;
$doc = simplexml_load_string($xml);
echo $doc->asXML();
echo print_r($doc);
This is not a problem with loading for me - I am building my SimpleXML object
dynamically.
The output from asXML() is correct.
The output from print_r() is not.
The output using attributes() (in a more complex example) is not correct,
although this simple test does work.
I am experiencing this on various versions of PHP 5.3.X on Windows Vista and
Ubuntu 11.10.
(ubuntu)$ php -v
PHP 5.3.2-1ubuntu4.9 with Suhosin-Patch (cli) (built: May 3 2011 00:45:52)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Suhosin v0.9.29, Copyright (c) 2007, by SektionEins GmbH
(Windows)>php -v
PHP 5.3.8 (cli) (built: Sep 22 2011 20:51:51)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
Previous Comments:
[2012-04-02 06:41:26] ahar...@php.net
I can't reproduce this:
text content
EOX;
$doc = simplexml_load_string($xml);
printf("Text content: %s; attribute: %s\n", $doc->child, $doc->child['attr']);
?>
Outputs "Text content: text content; attribute: foo", as I'd expect. Are you
able to provide a reproduction script?
The SO discussion appears to be about JSON encoding only; given that
SimpleXMLElement doesn't support serialisation, I'd suggest that the same would
apply to JSON encoding.
[2012-04-02 03:37:26] drgroove at gmail dot com
Description:
When loading XML into SimpleXML, tags which have both attributes and text will
have their attributes dropped.
For example, loading this into SimpleXML:
Here is some text
Will cause 'attribute="value"' to be lost. If there is no text w/in a tag, but
attributes, the attributes and their values are preserved.
I'm not the only PHP developer to notice this bug; please see:
http://stackoverflow.com/questions/8563073/disappearing-attributes-in-php-simplexml-object
I didn't see this bug reported on php.net, however.
Test script:
---
See above.
Expected result:
Tags with both attributes and text should not have their attributes dropped.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61597&edit=1
Bug #61577 [Asn]: php5ts.dll crashes when specific extensions are loaded
Edit report at https://bugs.php.net/bug.php?id=61577&edit=1 ID: 61577 User updated by:uniflare at gmail dot com Reported by:uniflare at gmail dot com Summary:php5ts.dll crashes when specific extensions are loaded Status: Assigned Type: Bug Package:Reproducible crash Operating System: Windows7 Ultimate x86 PHP Version:5.4.0 Assigned To:mattficken Block user comment: N Private report: N New Comment: @pajoye at php dotnet REVELATION: Please see below, I seem to have solved my problem; === Ill explain what you asked for anyway. Tried these configurations (all other extensions disabled, default php.ini). -- 1 ;extension=php_mbstring.dll extension=php_bz2.dll extension=php_gd2.dll -- 2 extension=php_mbstring.dll ;extension=php_bz2.dll extension=php_gd2.dll -- 3 extension=php_mbstring.dll extension=php_bz2.dll ;extension=php_gd2.dll. These above all work fine. -- But this does not work in 5.4.0: extension=php_mbstring.dll extension=php_bz2.dll extension=php_gd2.dll --- DLL Versions-- Default ext files from http://windows.php.net/downloads/releases/php-5.4.0-Win32-VC9-x86.zip File versions all report: 5.4.0.0 / Mod@ 29/02/12 19:39 === Note; Using the RC8 Version I have done some more testing and it appears there is something happening once php has parsed the file. I have this code in a file: If I stop the browser from continuing to load the page it gives me the entire phpinfo output with the 3 modules apparently enabled. Although event viewer still reports a crash. Apache error log has nothing about this error, neither does php error log (php_startup etc variables enabled ofc). === Revelation!?; Now back with 5.4.0 Official, re-ran phpinfo.php with all 3 ext enabled and now it shows the page properly with NO CRASH Strangely fixed!? All versions now working; Apache 2.4.1/Apache2.2.17 + PHP 5.4.0/PHP 5.3.10 Following Ext enabled on working 5.4.0 Offical: extension=php_mbstring.dll extension=php_bz2.dll extension=php_gd2.dll extension=php_curl.dll extension=php_mysql.dll extension=php_mysqli.dll extension=php_sqlite3.dll extension=php_fileinfo.dll extension=php_gettext.dll extension=php_intl.dll extension=php_pdo_mysql.dll extension=php_pdo_sqlite.dll extension=php_sockets.dll extension=php_tidy.dll extension=php_xmlrpc.dll extension=php_exif.dll Only the 3 ext causing issues were enabled in RC8 dir. This is extremely puzzling. Steps I took while testing: Replace the official 5.4.0 dir with the RC8 5.4.0 dir, Restart and test error several times trying to stop processing of phpinfo page long enough to look. Re-replace 5.4.0RC8 dir to Official. Re-Test.. no Crash.. Fixed? === Testing RC8 Again.. phpinfo page loads and crashes once loaded. Everytime. (5/5). Official Once again.. Everything works fine... === This leads me to believe RC8 has had some part in this. Perhaps a remnant dynamic configuration with apache. For now, I appear to have solved my problem. But I do still believe there is some inherent instability with these 3 extensions even in the official build. Thanks Previous Comments: [2012-04-12 17:56:09] paj...@php.net You said "I removed some and it works", or something along this line... @matt, please follow that further. As in, load this 3 DLLs with the given versions and see if it works in the same configuration. [2012-04-12 17:20:10] uniflare at gmail dot com @pajoye at php dot net Are you unable to read the original bug report or something, the dll files in question were mentioned in the description... This should be looked into, it means you cannot use mbstring, curl and GD2 at the same time, which is not good at all. They all serve a very useful purpose. There is obviously some compatibility issue with these dll's. If you cannot read the original bug report, then here; php_mbstring.dll php_gd2.dll php_curl.dll -- This is using a default setup as explained above on a system more than capable. And trust me, I am by far no beginner in using PHP, compiling my own versions with custom extensions etc. Trust me when i say, this should not be happening. PHP5.3.10 has NO problems using all 3 extensions. only PHP 5.4.0. Thanks. [2012-04-12 16:55:54] jmquarck at gmail dot com Using Windows 7 Ultimate 64 bits with PHP 5.4 and Apache 2.4 or Apache 2.2 http://localhost OK http://localhost/phpinfo.phpcrashes and changes url to www.localhost.com/phpinfo.php It happens even if mbstring, curl and g2 extensions are disabled. -
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1
ID: 54547
Comment by: b at hotmail dot vom
Reported by:peter dot ritt at gmx dot net
Summary:wrong equality of string numbers
Status: Verified
Type: Bug
Package:Unknown/Other Function
Operating System: linux
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
I would like to point out Perl is a weakly typed language, just like PHP, and
has
no issue with these cases. It's pretty weak from the developers to hide behind
the "But PHP is weakly typed!" argument.
Previous Comments:
[2012-04-12 17:09:41] riel at surriel dot com
Conversion of numeric-looking strings to numbers does not have to be a problem,
as long as the code in the back end uses arbitrary-precision math. This is
slower than comparing a type that fits in a CPU register, but once you have
already spent the time to do an automatic type conversion, that really does not
matter.
When it comes to an operator like ==, every digit matters. Having == return
false when two items are different violates the principle of least surprise.
[2012-04-12 17:03:32] jacob at fakku dot net
@rasmus
I just wanted to point out the issue mentioned in that article and how I felt
it
applied to this situation.
At least to me, it seems to me that it's a big deal when '9223372036854775807'
==
'9223372036854775808' returns true, even if it's an edge case. But you're right
about just using ===, which I will do if I ever run into this situation. After
doing a bit more research I can understand why it is the way it is and I was
probably too hasty to jump into this thread.
[2012-04-12 16:53:54] ras...@php.net
@jacob PHP has two sets of comparison operators as well. == and ===
They aren't numeric and string, they are loose and strict. In the majority of
cases when dealing with HTTP requests and database results, which is what PHP
deals with most, the loose comparison makes life easiest on the developer.
In your case when comparison huge numeric strings that won't fit in any numeric
type, a strict comparison is needed:
$ php -r 'var_dump("61529519452809720693702583126814" ===
"6152951945280972");'
bool(false)
(and hopefully you aren't actually using md5 for password hashing)
[2012-04-12 16:04:03] jacob at fakku dot net
I'm just gonna paste in that PHP Sadness article to show why this is such a big
issue.
According to php language.operators.comparison, the type-coercing comparison
operators will coerce both operands to floats if they both look like numbers,
even if they are both already strings:
If you compare a number with a string or the comparison involves numerical
strings, then each string is converted to a number and the comparison performed
numerically.
This can become especially important in situations where the developer chooses
to use == to compare two values which will always be strings. For example,
consider a simple password checker:
if (md5($password) == $hash) {
print "Allowed!\n";
}
Assume that the $hash is loaded from a known safe string value from a database
and contains a real MD5 hash. Now, suppose the $password is "ximaz", which has
an all-numeric hex-encoded MD5 hash of "61529519452809720693702583126814". When
PHP does the comparison, it will print "Allowed!" for any password which
matches
even the first half of the hash:
$ php -r 'var_dump("61529519452809720693702583126814" ==
"6152951945280972");'
bool(true)
The solution, of course, is "never use type-coercing comparison operators" -
but
this remains an easily-overlooked bug factory for beginning and even
intermediate developers. Some languages solve this situation by having two
separate sets of comparison operators for numeric or string comparisons so that
the developer can be explicit in their intent without needing to manually cast
their arguments.
[2012-04-12 15:55:26] yless42 at hotmail dot com
Wouldn't it make the most sense to compare the strings as string (and thus pass
in the original case), then fall back on other comparison methods when they
don't match? I admit I don't have test cases but it seems that this would be
backwards compatible in most cases (as you will eventually compare numerically)
and fix the given issue.
Unless there are cases which rely on the two same strings failing to compare as
equal.
The remainder of the comments for this report are
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1
ID: 54547
Comment by: elementation at gmail dot com
Reported by:peter dot ritt at gmx dot net
Summary:wrong equality of string numbers
Status: Verified
Type: Bug
Package:Unknown/Other Function
Operating System: linux
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
It's absolutely unreal that this is even a discussion. PHP, the world doesn't
take you seriously and with bugs like this you provide further fodder.
Principle of Least Surprise â this should be a string comparison.
Previous Comments:
[2012-04-12 20:32:57] b at hotmail dot vom
I would like to point out Perl is a weakly typed language, just like PHP, and
has
no issue with these cases. It's pretty weak from the developers to hide behind
the "But PHP is weakly typed!" argument.
[2012-04-12 17:09:41] riel at surriel dot com
Conversion of numeric-looking strings to numbers does not have to be a problem,
as long as the code in the back end uses arbitrary-precision math. This is
slower than comparing a type that fits in a CPU register, but once you have
already spent the time to do an automatic type conversion, that really does not
matter.
When it comes to an operator like ==, every digit matters. Having == return
false when two items are different violates the principle of least surprise.
[2012-04-12 17:03:32] jacob at fakku dot net
@rasmus
I just wanted to point out the issue mentioned in that article and how I felt
it
applied to this situation.
At least to me, it seems to me that it's a big deal when '9223372036854775807'
==
'9223372036854775808' returns true, even if it's an edge case. But you're right
about just using ===, which I will do if I ever run into this situation. After
doing a bit more research I can understand why it is the way it is and I was
probably too hasty to jump into this thread.
[2012-04-12 16:53:54] ras...@php.net
@jacob PHP has two sets of comparison operators as well. == and ===
They aren't numeric and string, they are loose and strict. In the majority of
cases when dealing with HTTP requests and database results, which is what PHP
deals with most, the loose comparison makes life easiest on the developer.
In your case when comparison huge numeric strings that won't fit in any numeric
type, a strict comparison is needed:
$ php -r 'var_dump("61529519452809720693702583126814" ===
"6152951945280972");'
bool(false)
(and hopefully you aren't actually using md5 for password hashing)
[2012-04-12 16:04:03] jacob at fakku dot net
I'm just gonna paste in that PHP Sadness article to show why this is such a big
issue.
According to php language.operators.comparison, the type-coercing comparison
operators will coerce both operands to floats if they both look like numbers,
even if they are both already strings:
If you compare a number with a string or the comparison involves numerical
strings, then each string is converted to a number and the comparison performed
numerically.
This can become especially important in situations where the developer chooses
to use == to compare two values which will always be strings. For example,
consider a simple password checker:
if (md5($password) == $hash) {
print "Allowed!\n";
}
Assume that the $hash is loaded from a known safe string value from a database
and contains a real MD5 hash. Now, suppose the $password is "ximaz", which has
an all-numeric hex-encoded MD5 hash of "61529519452809720693702583126814". When
PHP does the comparison, it will print "Allowed!" for any password which
matches
even the first half of the hash:
$ php -r 'var_dump("61529519452809720693702583126814" ==
"6152951945280972");'
bool(true)
The solution, of course, is "never use type-coercing comparison operators" -
but
this remains an easily-overlooked bug factory for beginning and even
intermediate developers. Some languages solve this situation by having two
separate sets of comparison operators for numeric or string comparisons so that
the developer can be explicit in their intent without needing to manually cast
their arguments.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=54547
--
Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1
ID: 54547
Comment by: c at hotmail dot com
Reported by:peter dot ritt at gmx dot net
Summary:wrong equality of string numbers
Status: Verified
Type: Bug
Package:Unknown/Other Function
Operating System: linux
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
"In the majority of cases when dealing with HTTP requests and database results,
which is what PHP deals with most, the loose comparison makes life easiest on
the developer."
By 'the developer' I assume you mean people who can't type (string) or (int) ?
No other language has this issue because they aren't designed around
programmers who do not really understand how to program. Please make the
developer's life easier by making comparisons make sense.
Previous Comments:
[2012-04-12 20:38:48] elementation at gmail dot com
It's absolutely unreal that this is even a discussion. PHP, the world doesn't
take you seriously and with bugs like this you provide further fodder.
Principle of Least Surprise â this should be a string comparison.
[2012-04-12 20:32:57] b at hotmail dot vom
I would like to point out Perl is a weakly typed language, just like PHP, and
has
no issue with these cases. It's pretty weak from the developers to hide behind
the "But PHP is weakly typed!" argument.
[2012-04-12 17:09:41] riel at surriel dot com
Conversion of numeric-looking strings to numbers does not have to be a problem,
as long as the code in the back end uses arbitrary-precision math. This is
slower than comparing a type that fits in a CPU register, but once you have
already spent the time to do an automatic type conversion, that really does not
matter.
When it comes to an operator like ==, every digit matters. Having == return
false when two items are different violates the principle of least surprise.
[2012-04-12 17:03:32] jacob at fakku dot net
@rasmus
I just wanted to point out the issue mentioned in that article and how I felt
it
applied to this situation.
At least to me, it seems to me that it's a big deal when '9223372036854775807'
==
'9223372036854775808' returns true, even if it's an edge case. But you're right
about just using ===, which I will do if I ever run into this situation. After
doing a bit more research I can understand why it is the way it is and I was
probably too hasty to jump into this thread.
[2012-04-12 16:53:54] ras...@php.net
@jacob PHP has two sets of comparison operators as well. == and ===
They aren't numeric and string, they are loose and strict. In the majority of
cases when dealing with HTTP requests and database results, which is what PHP
deals with most, the loose comparison makes life easiest on the developer.
In your case when comparison huge numeric strings that won't fit in any numeric
type, a strict comparison is needed:
$ php -r 'var_dump("61529519452809720693702583126814" ===
"6152951945280972");'
bool(false)
(and hopefully you aren't actually using md5 for password hashing)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=54547
--
Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
Bug #60794 [Com]: Cannot include files from different .phars when include path is too long
Edit report at https://bugs.php.net/bug.php?id=60794&edit=1 ID: 60794 Comment by: alex dot bowyer at googlemail dot com Reported by:pdobrigkeit at gmx dot de Summary:Cannot include files from different .phars when include path is too long Status: Open Type: Bug Package:PHAR related Operating System: Windows 7 PHP Version:5.3.9 Block user comment: N Private report: N New Comment: I have the same problem on PHP 5.3.10 / Windows Server 2008 / IIS 7.5. We have a workaround for now but soon the 218 character limit is going to be an issue for us. Hope you can fix it! Previous Comments: [2012-01-19 10:39:19] s dot kleff at dershao dot de Works as expected on PHP Version 5.3.8-ZS5.5.0 / Debian 2.6.32-5-amd64 [2012-01-19 07:59:10] s dot kleff at dershao dot de Same on PHP 5.3.8 on Win 7 64Bit [2012-01-18 18:27:10] pdobrigkeit at gmx dot de Description: When including multiple .phar archieves into the code and one of the archieves contains for example an autoloading script to include files, the script breaks when the reference to the phar wrapper is too far back in the include path. It works anytime when using the phar:// wrapper and not when referencing the file via the include path. That is not helpful, when the provided autoloader of the framework does not care whether the file is within a different .phar. The two used .phars used can be downloaded here: http://dl.dropbox.com/u/3319901/autoload.phar http://dl.dropbox.com/u/3319901/libA.phar Just put those into the root directory with the test script code. To build the .phars I used the export functionality of Zend Studio, as well as a Phing target, both yielded the same results. Test script: --- https://bugs.php.net/bug.php?id=60794&edit=1
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1 ID: 54547 Comment by: vinny_182 at hotmail dot com Reported by:peter dot ritt at gmx dot net Summary:wrong equality of string numbers Status: Verified Type: Bug Package:Unknown/Other Function Operating System: linux PHP Version:5.3.6 Assigned To:dmitry Block user comment: N Private report: N New Comment: Equality is equality and neither string or numeric representations of the value are equal. The bug IMO is in the conversion from string to float, the conversion has failed but a valid value is still returned. That's just plain wrong. If you wrote unit tests for string to float conversions and this was the input you would expect it to return a null value or throw an exception. Previous Comments: [2012-04-12 21:02:06] c at hotmail dot com "In the majority of cases when dealing with HTTP requests and database results, which is what PHP deals with most, the loose comparison makes life easiest on the developer." By 'the developer' I assume you mean people who can't type (string) or (int) ? No other language has this issue because they aren't designed around programmers who do not really understand how to program. Please make the developer's life easier by making comparisons make sense. [2012-04-12 20:38:48] elementation at gmail dot com It's absolutely unreal that this is even a discussion. PHP, the world doesn't take you seriously and with bugs like this you provide further fodder. Principle of Least Surprise â this should be a string comparison. [2012-04-12 20:32:57] b at hotmail dot vom I would like to point out Perl is a weakly typed language, just like PHP, and has no issue with these cases. It's pretty weak from the developers to hide behind the "But PHP is weakly typed!" argument. [2012-04-12 17:09:41] riel at surriel dot com Conversion of numeric-looking strings to numbers does not have to be a problem, as long as the code in the back end uses arbitrary-precision math. This is slower than comparing a type that fits in a CPU register, but once you have already spent the time to do an automatic type conversion, that really does not matter. When it comes to an operator like ==, every digit matters. Having == return false when two items are different violates the principle of least surprise. [2012-04-12 17:03:32] jacob at fakku dot net @rasmus I just wanted to point out the issue mentioned in that article and how I felt it applied to this situation. At least to me, it seems to me that it's a big deal when '9223372036854775807' == '9223372036854775808' returns true, even if it's an edge case. But you're right about just using ===, which I will do if I ever run into this situation. After doing a bit more research I can understand why it is the way it is and I was probably too hasty to jump into this thread. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54547 -- Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1 ID: 54547 Comment by: chx1975 at gmail dot com Reported by:peter dot ritt at gmx dot net Summary:wrong equality of string numbers Status: Verified Type: Bug Package:Unknown/Other Function Operating System: linux PHP Version:5.3.6 Assigned To:dmitry Block user comment: N Private report: N New Comment: Now, while I can understand why PHP chooses "1" == 1 (HTML, sure) I am not too sure how is that relevant when both sides are strings?? I am not quite sure why the strings "1" and "1.0" would need to be ==. Just because "1" == 1 and "1.0" == 1 does not mean "1" == "1.0". It's not transitive! Compare FALSE == 0; 0 == 'x'; 'x' == TRUE -- if it would be transitive then FALSE == TRUE, surely you don't want that. Previous Comments: [2012-04-12 21:23:40] vinny_182 at hotmail dot com Equality is equality and neither string or numeric representations of the value are equal. The bug IMO is in the conversion from string to float, the conversion has failed but a valid value is still returned. That's just plain wrong. If you wrote unit tests for string to float conversions and this was the input you would expect it to return a null value or throw an exception. [2012-04-12 21:02:06] c at hotmail dot com "In the majority of cases when dealing with HTTP requests and database results, which is what PHP deals with most, the loose comparison makes life easiest on the developer." By 'the developer' I assume you mean people who can't type (string) or (int) ? No other language has this issue because they aren't designed around programmers who do not really understand how to program. Please make the developer's life easier by making comparisons make sense. [2012-04-12 20:38:48] elementation at gmail dot com It's absolutely unreal that this is even a discussion. PHP, the world doesn't take you seriously and with bugs like this you provide further fodder. Principle of Least Surprise â this should be a string comparison. [2012-04-12 20:32:57] b at hotmail dot vom I would like to point out Perl is a weakly typed language, just like PHP, and has no issue with these cases. It's pretty weak from the developers to hide behind the "But PHP is weakly typed!" argument. [2012-04-12 17:09:41] riel at surriel dot com Conversion of numeric-looking strings to numbers does not have to be a problem, as long as the code in the back end uses arbitrary-precision math. This is slower than comparing a type that fits in a CPU register, but once you have already spent the time to do an automatic type conversion, that really does not matter. When it comes to an operator like ==, every digit matters. Having == return false when two items are different violates the principle of least surprise. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54547 -- Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
[PHP-BUG] Bug #61706 [NEW]: escapeshellarg behaves inconsistently depending on shell
From: Operating system: Linux, Unix, maybe OSX, NOT msw PHP version: 5.4Git-2012-04-12 (Git) Package: Program Execution Bug Type: Bug Bug description:escapeshellarg behaves inconsistently depending on shell Description: Depending on the shell, for shell internal commands the backslashes within single quotes are interpreted as escapes or are used verbatim. For example, in bash and in busybox: $ echo '\\' \\ But in dash: $ echo '\\' \ dash is frequently set as the default /bin/sh so this is a problem. More so since some programs need to get their input from stdin and therefore they need the use of 'echo' for input not coming from a file or being input from the console. To work around the backslash inconsistency among shells, backslashes should receive special treatment as quotes do, e.g. translate \ to '\\'. I was tempted of sending this as a security issue, but the scenarios where security could be in risk are too improbable for it to be a serious security concern. Ideally though, no unnecessary quotes should be used in the output string, e.g. escapeshellarg should convert '''abc\\'\ into \'\'\''abc'\'\\. Currently it converts '''abc\\'\ into ''\'''\'''\''abc\\'\''\' which exhibits the bug and is unnecessarily large. For backwards compatibility, maybe an extra argument should be added to also quote backslashes and use a new method of quoting. Here is a PHP function that implements the suggestions here, using strspn and strcspn to grab the longest spans that it can "eat" at a time of each kind (characters to escape / characters not to escape): http://www.formauri.es/personal/pgimeno/temp/sh_escape.phps (includes test suite). Test script: --- Expected result: No matter the shell: \\ Actual result: -- If your /bin/sh is dash: \ If your /bin/sh is busybox: \\ Other shells: ?? -- Edit bug report at https://bugs.php.net/bug.php?id=61706&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61706&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61706&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61706&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61706&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61706&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61706&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61706&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61706&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61706&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61706&r=support Expected behavior: https://bugs.php.net/fix.php?id=61706&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61706&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61706&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61706&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61706&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61706&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61706&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61706&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61706&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61706&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61706&r=mysqlcfg
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1 ID: 54547 Comment by: erowid at inbox dot lv Reported by:peter dot ritt at gmx dot net Summary:wrong equality of string numbers Status: Verified Type: Bug Package:Unknown/Other Function Operating System: linux PHP Version:5.3.6 Assigned To:dmitry Block user comment: N Private report: N New Comment: I want to marry it, lather this thread up, and have my way with it. I want to have little threads everywhere that are as funny as this xD Previous Comments: [2012-04-12 22:14:36] chx1975 at gmail dot com Now, while I can understand why PHP chooses "1" == 1 (HTML, sure) I am not too sure how is that relevant when both sides are strings?? I am not quite sure why the strings "1" and "1.0" would need to be ==. Just because "1" == 1 and "1.0" == 1 does not mean "1" == "1.0". It's not transitive! Compare FALSE == 0; 0 == 'x'; 'x' == TRUE -- if it would be transitive then FALSE == TRUE, surely you don't want that. [2012-04-12 21:23:40] vinny_182 at hotmail dot com Equality is equality and neither string or numeric representations of the value are equal. The bug IMO is in the conversion from string to float, the conversion has failed but a valid value is still returned. That's just plain wrong. If you wrote unit tests for string to float conversions and this was the input you would expect it to return a null value or throw an exception. [2012-04-12 21:02:06] c at hotmail dot com "In the majority of cases when dealing with HTTP requests and database results, which is what PHP deals with most, the loose comparison makes life easiest on the developer." By 'the developer' I assume you mean people who can't type (string) or (int) ? No other language has this issue because they aren't designed around programmers who do not really understand how to program. Please make the developer's life easier by making comparisons make sense. [2012-04-12 20:38:48] elementation at gmail dot com It's absolutely unreal that this is even a discussion. PHP, the world doesn't take you seriously and with bugs like this you provide further fodder. Principle of Least Surprise â this should be a string comparison. [2012-04-12 20:32:57] b at hotmail dot vom I would like to point out Perl is a weakly typed language, just like PHP, and has no issue with these cases. It's pretty weak from the developers to hide behind the "But PHP is weakly typed!" argument. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54547 -- Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
Bug #61423 [Asn]: gzip compression fails
Edit report at https://bugs.php.net/bug.php?id=61423&edit=1 ID: 61423 User updated by:borrible13th at gmx dot net Reported by:borrible13th at gmx dot net Summary:gzip compression fails Status: Assigned Type: Bug Package:SOAP related Operating System: ALL PHP Version:5.4.0 Assigned To:iliaa Block user comment: N Private report: N New Comment: Please cherry-pick commit 9c5ae99 into branch 5.4.1. The bugfix is still missing there, although the bug is listed as fixed in https://github.com/php/php- src/blob/PHP-5.4.1/NEWS#L85 (line 85). Previous Comments: [2012-04-03 12:49:44] il...@php.net Automatic comment on behalf of iliaa Revision: http://git.php.net/?p=php-src.git;a=commit;h=9c5ae9954f40c82ee98038ce3e528185090e4ba1 Log: Fixed bug #61423 (gzip compression fails). [2012-04-03 12:47:07] il...@php.net Automatic comment on behalf of iliaa Revision: http://git.php.net/?p=php-src.git;a=commit;h=9c5ae9954f40c82ee98038ce3e528185090e4ba1 Log: Fixed bug #61423 (gzip compression fails). [2012-03-29 04:24:02] ili...@php.net Automatic comment on behalf of iliaal Revision: http://git.php.net/?p=php-src.git;a=commit;h=b4aea52682a6e7a8f0e2a7638ba37145cb6bf16d Log: Fixed bug #61423 (gzip compression fails). [2012-03-29 04:24:01] il...@php.net Automatic comment on behalf of iliaa Revision: http://git.php.net/?p=php-src.git;a=commit;h=f9f631fb765dc08e3d62073b6eb35ce1b11db0e4 Log: Fixed bug #61423 (gzip compression fails). [2012-03-26 13:28:51] borrible13th at gmx dot net "Merge branch 'PHP-5.3' into PHP-5.4" (7a1c765385) reverted this bugfix! :( Please re-commit it to branch PHP-5.4 only. Thanks in advance! 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=61423 -- Edit this bug report at https://bugs.php.net/bug.php?id=61423&edit=1
Req #61703 [Opn->Nab]: sort-array
Edit report at https://bugs.php.net/bug.php?id=61703&edit=1 ID: 61703 Updated by: ahar...@php.net Reported by:sia88 at utexas dot edu Summary:sort-array -Status: Open +Status: Not a bug Type: Feature/Change Request Package:Arrays related Operating System: pc PHP Version:5.3.10 Block user comment: N Private report: N New Comment: What admin said. Previous Comments: [2012-04-12 19:12:08] admin at sinfocol dot org The feature is already implemented in another function called asort. [2012-04-12 19:00:14] sia88 at utexas dot edu Description: --- >From manual page: http://www.php.net/function.sort --- I wanted to request a feature to the sort function. I noticed it did not have optional parameter to retain the keys of the array. Instead it re-writes them. why not add an optional 3rd boolean paramter to decide to retain keys in the original array or not? -- Edit this bug report at https://bugs.php.net/bug.php?id=61703&edit=1
Bug #61156 [Com]: Segfault when using get_defined_constants(true)
Edit report at https://bugs.php.net/bug.php?id=61156&edit=1 ID: 61156 Comment by: david at panmedia dot co dot nz Reported by:damien at overeem dot org Summary:Segfault when using get_defined_constants(true) Status: Not a bug Type: Bug Package:Reproducible crash Operating System: openSUSE 11.4 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: This is happening for me too on PHP 5.4 built in server Windows 7 64bit (no suhosin), and on Ubuntu with fast CGI, and the built in server. Its fine on a simple test case like 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. [2012-02-23 08:48:12] damien at overeem dot org Something important that I forgot, definatly noteworthy while testing. After an apache RESTART, the issue does not exist. But if one performs an apache RELOAD, the problem raises its ugly head. Though sometimes it takes 2-3 reloads before it happens. So please, when testing, start up apache and do 2-3 apache reloads and then check if the problem shows up. [2012-02-23 08:18:25] damien at overeem dot org Thank you for testing carloschilazo. It would be quite nasty if this issue still caused a crash in 5.3.10. It would be good to know if this issue was specifically adressed in one of the updates between 5.3.5. and 5.3.10 though. Unfortunately it would be quite hard to test against exactly the same circumstances (same libraries, apache version, combination of modules etc.). In any case i'm happy that this problem does not exist in 5.3.10. [2012-02-23 03:43:13] carloschilazo at gmail dot com Could not reproduce on 5.3.10, this can be closed [2012-02-21 16:08:28] damien at overeem dot org Description: ATTN: This is a bug in php verison 5.3.5 !! I do realize that this is about an earlier version, but I have no available environments on which i could simply upgrade. So consider this bug report as a notification. It can be closed if not considered a valid report. We resolved our issue by circumventing use of the categorization of get_defined_constants. The function get_defined_constants(true) causes a client segfault ([Tue Feb 21 16:18:24 2012] [notice] child pid 12564 exit signal Segmentation fault (11)) There are some references to this issue occurring ie. #51788. In that particular case however, the issue seemed to have been caused by suhosin. My installation is running native php2 engine v2.3.0. When using get_defined_constants() (without the categorization parameter) there is no problem. Further information: OS: openSUSE 11.4 Kernel: 2.6.37.6-0.11-default Apache version: 2.2.17 ( API Version 20051115) PHP Version: 5.3.5 Loaded modules: core prefork http_core mod_so mod_unique_id mod_actions mod_alias mod_auth_basic mod_authn_file mod_authz_host mod_authz_groupfile mod_authz_default mod_authz_user mod_authn_dbm mod_autoindex mod_cgi mod_dir mod_env mod_expires mod_include mod_log_config mod_mime mod_negotiation mod_setenvif mod_ssl mod_status mod_suexec mod_userdir mod_vhost_alias mod_rewrite mod_php5 mod_info mod_dav mod_deflate mod_proxy mod_proxy_http Test script: --- Expected result: No output, no error logging. Actual result: -- Output: Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data. Apache error log: [Tue Feb 21 16:18:24 2012] [notice] child pid 12564 exit signal Segmentation fault (11) -- Edit this bug report at https://bugs.php.net/bug.php?id=61156&edit=1
Bug #61706 [Com]: escapeshellarg behaves inconsistently depending on shell
Edit report at https://bugs.php.net/bug.php?id=61706&edit=1 ID: 61706 Comment by: zhanglijiu at gmail dot com Reported by:phpbugs at personal dot formauri dot es Summary:escapeshellarg behaves inconsistently depending on shell Status: Open Type: Bug Package:Program Execution Operating System: Linux, Unix, maybe OSX, NOT msw PHP Version:5.4Git-2012-04-12 (Git) Block user comment: N Private report: N New Comment: My result is \\ my system is Mac OS SHould be bash Previous Comments: [2012-04-12 22:22:04] phpbugs at personal dot formauri dot es Description: Depending on the shell, for shell internal commands the backslashes within single quotes are interpreted as escapes or are used verbatim. For example, in bash and in busybox: $ echo '\\' \\ But in dash: $ echo '\\' \ dash is frequently set as the default /bin/sh so this is a problem. More so since some programs need to get their input from stdin and therefore they need the use of 'echo' for input not coming from a file or being input from the console. To work around the backslash inconsistency among shells, backslashes should receive special treatment as quotes do, e.g. translate \ to '\\'. I was tempted of sending this as a security issue, but the scenarios where security could be in risk are too improbable for it to be a serious security concern. Ideally though, no unnecessary quotes should be used in the output string, e.g. escapeshellarg should convert '''abc\\'\ into \'\'\''abc'\'\\. Currently it converts '''abc\\'\ into ''\'''\'''\''abc\\'\''\' which exhibits the bug and is unnecessarily large. For backwards compatibility, maybe an extra argument should be added to also quote backslashes and use a new method of quoting. Here is a PHP function that implements the suggestions here, using strspn and strcspn to grab the longest spans that it can "eat" at a time of each kind (characters to escape / characters not to escape): http://www.formauri.es/personal/pgimeno/temp/sh_escape.phps (includes test suite). Test script: --- Expected result: No matter the shell: \\ Actual result: -- If your /bin/sh is dash: \ If your /bin/sh is busybox: \\ Other shells: ?? -- Edit this bug report at https://bugs.php.net/bug.php?id=61706&edit=1
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1 ID: 54547 Comment by: the dot matt dot kantor at gmail dot com Reported by:peter dot ritt at gmx dot net Summary:wrong equality of string numbers Status: Verified Type: Bug Package:Unknown/Other Function Operating System: linux PHP Version:5.3.6 Assigned To:dmitry Block user comment: N Private report: N New Comment: @hholzgra: Your only-coerce-on-failure proposal would not solve this issue. Assuming that by "fail" you mean "the comparison evaluates to false", the strings would end up being coerced anyway (since they are indeed different), they'd become identical floats, and things would be the same as they are now. If I misunderstood what you meant by "fail", then we'd lose "1" == "1.0", which I don't think is something that can (or should) happen. Previous Comments: [2012-04-12 22:45:28] erowid at inbox dot lv I want to marry it, lather this thread up, and have my way with it. I want to have little threads everywhere that are as funny as this xD [2012-04-12 22:14:36] chx1975 at gmail dot com Now, while I can understand why PHP chooses "1" == 1 (HTML, sure) I am not too sure how is that relevant when both sides are strings?? I am not quite sure why the strings "1" and "1.0" would need to be ==. Just because "1" == 1 and "1.0" == 1 does not mean "1" == "1.0". It's not transitive! Compare FALSE == 0; 0 == 'x'; 'x' == TRUE -- if it would be transitive then FALSE == TRUE, surely you don't want that. [2012-04-12 21:23:40] vinny_182 at hotmail dot com Equality is equality and neither string or numeric representations of the value are equal. The bug IMO is in the conversion from string to float, the conversion has failed but a valid value is still returned. That's just plain wrong. If you wrote unit tests for string to float conversions and this was the input you would expect it to return a null value or throw an exception. [2012-04-12 21:02:06] c at hotmail dot com "In the majority of cases when dealing with HTTP requests and database results, which is what PHP deals with most, the loose comparison makes life easiest on the developer." By 'the developer' I assume you mean people who can't type (string) or (int) ? No other language has this issue because they aren't designed around programmers who do not really understand how to program. Please make the developer's life easier by making comparisons make sense. [2012-04-12 20:38:48] elementation at gmail dot com It's absolutely unreal that this is even a discussion. PHP, the world doesn't take you seriously and with bugs like this you provide further fodder. Principle of Least Surprise â this should be a string comparison. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54547 -- Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
Bug #61701 [Opn->Nab]: asXML function returns string that cannot be casted as integer
Edit report at https://bugs.php.net/bug.php?id=61701&edit=1
ID: 61701
Updated by: ahar...@php.net
Reported by:petri dot peltoniemi at prosys dot fi
Summary:asXML function returns string that cannot be casted
as integer
-Status: Open
+Status: Not a bug
Type: Bug
Package:SimpleXML related
Operating System: Linux / ubuntu
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
asXML() returns either a full XML document or an XML fragment for an element or
attribute. Either way, it's not going to look like a numeric string, since
there'll be an enclosing element or attribute definition, and therefore a
typecast
to integer will fail.
Previous Comments:
[2012-04-12 13:58:08] petri dot peltoniemi at prosys dot fi
Description:
---
>From manual page: http://www.php.net/simplexmlelement.asxml
---
I have array of arrays like
$result = array();
foreach ($wholesalers as $wholesaler) {
$result[] = array("Saldo" => $wholesaler->Available->asXML());
}
Available tag contains numeric value (integer) that should now be in string
This simplexml generated string cannot by typecasted to integer
Test script:
---
funtion SortSaldos($array1, $array2) {
$saldo1 = $array1['Saldo'];
$saldo2 = $array2['Saldo'];
echo "type: " . gettype($saldo1) . " $saldo1 as int " . intval($saldo1)
. " vs $saldo2 " . gettype($saldo2) . " as int " . intval($saldo2) . "";
echo "petri debug $saldo1 < $saldo2";
$saldo1 = intval($saldo1);
$saldo2 = intval($saldo2);
if ($saldo1 === $saldo2) {
echo " equal";
return 0;
}
if ($saldo1 < $saldo2) {
echo " -1 ";
return -1;
} else {
echo " 1 ";
return 1;
}
}
uasort($result, "SortSaldos");
and with the function I see my debug information on screen:
type: string 1 as int 0 vs 2 string as int 0
petri debug 1 < 2 equal
type: string 9 as int 0 vs 1 string as int 0
petri debug 9 < 1 equal
type: string 1 as int 0 vs 4 string as int 0
petri debug 1 < 4 equal
so intval is always failing for strings generated by simplexml->asXML -
function.
If I do my saldo with typecasting like this:
$result = array();
foreach ($wholesalers as $wholesaler) {
$result[] = array("Saldo" => (string) $wholesaler->Available);
}
everything works like expected
--
Edit this bug report at https://bugs.php.net/bug.php?id=61701&edit=1
[PHP-BUG] Req #61708 [NEW]: Untrusted input variables tagging to detect and prevent SQL injection
From: Operating system: PHP version: Irrelevant Package: MySQL related Bug Type: Feature/Change Request Bug description:Untrusted input variables tagging to detect and prevent SQL injection Description: I propose that PHP tag bytes in variables that come from untrusted sources such as user input (eg. $_GET $_POST $_COOKIE $_REQUEST etc..) or read from the database. For each php variable, there would be a piece of metadata that defines the byte ranges in that variable containing bytes from untrusted sources. This metadata would be updated whenever any php code or function changed the contents of a variable. This is a very simple concept in theory, but I am not sure how difficult it would be to implement in php. The mysql functions such as mysql_query() can then use the metadata to differentiate between bytes that come from untrusted sources from the part of the query that the programmer wrote. eg. in my test script below, mysql_query() would know that the $username and $password parts in the $query variable are untrusted and must be escaped. The php mysql functions can then alter the query to automatically add escaping before passing it on to mysql database thus making all SQL injection exploits obsolete without needing to rewrite any php code. This would work similar to magic quotes, without the problem of double escaping or display errors when the variables are displayed on a webpage instead of used in a database. A color diagram should make my idea more clear. http://img690.imageshack.us/img690/3313/mysqlinjection.png Test script: --- http://server/test.php?username=john&password=' OR 1=1 -- $username = $_GET['username']; $password = $_GET['password']; $query = "SELECT * FROM `users` WHERE `username` = '$username' AND `password` = '$password' "; $result = mysql_query ( $query ); ?> Expected result: mysql_query() would change the query to SELECT * FROM `users` WHERE `username` = 'john' AND `password` = '\' OR 1=1 --' Actual result: -- The query that gets executed SELECT * FROM `users` WHERE `username` = 'john' AND `password` = '' OR 1=1 --' -- Edit bug report at https://bugs.php.net/bug.php?id=61708&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61708&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61708&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61708&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61708&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61708&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61708&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61708&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61708&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61708&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61708&r=support Expected behavior: https://bugs.php.net/fix.php?id=61708&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61708&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61708&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61708&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61708&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61708&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61708&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61708&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61708&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61708&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61708&r=mysqlcfg
Bug #61597 [Fbk->Opn]: SimpleXMLElement doesn't include both @attributes and textContent in properties
Edit report at https://bugs.php.net/bug.php?id=61597&edit=1
ID: 61597
Updated by: ahar...@php.net
Reported by:drgroove at gmail dot com
-Summary:SimpleXML drops attributes for tags with both
attributes and text
+Summary:SimpleXMLElement doesn't include both @attributes
and textContent in properties
-Status: Feedback
+Status: Open
Type: Bug
Package:SimpleXML related
Operating System: Mac OS X
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Ah, I see what you're getting at now. Thanks. It appears to be an issue with
the
get_properties and get_debug_info handlers for SimpleXMLElement.
This has been reported and closed as a duplicate before, but I think that was
mistaken, as we don't have an open bug for this at present that I can find.
Previous Comments:
[2012-04-12 19:51:23] jplyon dot csu at gmail dot com
another test:
$xml = <<<'EOX'
corn
EOX;
$doc = simplexml_load_string($xml);
echo $doc->asXML();
echo print_r($doc);
This is not a problem with loading for me - I am building my SimpleXML object
dynamically.
The output from asXML() is correct.
The output from print_r() is not.
The output using attributes() (in a more complex example) is not correct,
although this simple test does work.
I am experiencing this on various versions of PHP 5.3.X on Windows Vista and
Ubuntu 11.10.
(ubuntu)$ php -v
PHP 5.3.2-1ubuntu4.9 with Suhosin-Patch (cli) (built: May 3 2011 00:45:52)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Suhosin v0.9.29, Copyright (c) 2007, by SektionEins GmbH
(Windows)>php -v
PHP 5.3.8 (cli) (built: Sep 22 2011 20:51:51)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
[2012-04-02 06:41:26] ahar...@php.net
I can't reproduce this:
text content
EOX;
$doc = simplexml_load_string($xml);
printf("Text content: %s; attribute: %s\n", $doc->child, $doc->child['attr']);
?>
Outputs "Text content: text content; attribute: foo", as I'd expect. Are you
able to provide a reproduction script?
The SO discussion appears to be about JSON encoding only; given that
SimpleXMLElement doesn't support serialisation, I'd suggest that the same would
apply to JSON encoding.
[2012-04-02 03:37:26] drgroove at gmail dot com
Description:
When loading XML into SimpleXML, tags which have both attributes and text will
have their attributes dropped.
For example, loading this into SimpleXML:
Here is some text
Will cause 'attribute="value"' to be lost. If there is no text w/in a tag, but
attributes, the attributes and their values are preserved.
I'm not the only PHP developer to notice this bug; please see:
http://stackoverflow.com/questions/8563073/disappearing-attributes-in-php-simplexml-object
I didn't see this bug reported on php.net, however.
Test script:
---
See above.
Expected result:
Tags with both attributes and text should not have their attributes dropped.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61597&edit=1
Req #61708 [Opn->Nab]: Untrusted input variables tagging to detect and prevent SQL injection
Edit report at https://bugs.php.net/bug.php?id=61708&edit=1 ID: 61708 Updated by: s...@php.net Reported by:forphponly at hostultra dot com Summary:Untrusted input variables tagging to detect and prevent SQL injection -Status: Open +Status: Not a bug Type: Feature/Change Request Package:MySQL related PHP Version:Irrelevant Block user comment: N Private report: N New Comment: See https://wiki.php.net/rfc/taint and http://pecl.php.net/package/taint Previous Comments: [2012-04-13 01:52:27] forphponly at hostultra dot com Description: I propose that PHP tag bytes in variables that come from untrusted sources such as user input (eg. $_GET $_POST $_COOKIE $_REQUEST etc..) or read from the database. For each php variable, there would be a piece of metadata that defines the byte ranges in that variable containing bytes from untrusted sources. This metadata would be updated whenever any php code or function changed the contents of a variable. This is a very simple concept in theory, but I am not sure how difficult it would be to implement in php. The mysql functions such as mysql_query() can then use the metadata to differentiate between bytes that come from untrusted sources from the part of the query that the programmer wrote. eg. in my test script below, mysql_query() would know that the $username and $password parts in the $query variable are untrusted and must be escaped. The php mysql functions can then alter the query to automatically add escaping before passing it on to mysql database thus making all SQL injection exploits obsolete without needing to rewrite any php code. This would work similar to magic quotes, without the problem of double escaping or display errors when the variables are displayed on a webpage instead of used in a database. A color diagram should make my idea more clear. http://img690.imageshack.us/img690/3313/mysqlinjection.png Test script: --- http://server/test.php?username=john&password=' OR 1=1 -- $username = $_GET['username']; $password = $_GET['password']; $query = "SELECT * FROM `users` WHERE `username` = '$username' AND `password` = '$password' "; $result = mysql_query ( $query ); ?> Expected result: mysql_query() would change the query to SELECT * FROM `users` WHERE `username` = 'john' AND `password` = '\' OR 1=1 --' Actual result: -- The query that gets executed SELECT * FROM `users` WHERE `username` = 'john' AND `password` = '' OR 1=1 --' -- Edit this bug report at https://bugs.php.net/bug.php?id=61708&edit=1
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1 ID: 54547 Comment by: four dot zero dot one dot unauthorized at gmail dot com Reported by:peter dot ritt at gmx dot net Summary:wrong equality of string numbers Status: Verified Type: Bug Package:Unknown/Other Function Operating System: linux PHP Version:5.3.6 Assigned To:dmitry Block user comment: N Private report: N New Comment: This behavior is documented here: http://php.net/manual/en/language.operators.comparison.php "If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number and the comparison performed numerically. These rules also apply to the switch statement. The type conversion does not take place when the comparison is === or !== as this involves comparing the type as well as the value. " Shouldn't this feature of converting numerical strings to numbers during loose comparison operations between two strings be dropped? If a developer wanted to compare values given during POST or GET processing AS numbers, they should cast the inputs to (int) or (float) first. There really should be a fundamental shift away from catering to developer laziness, and force developers to pay more attention to variable and input handling on their own. Previous Comments: [2012-04-13 01:10:44] the dot matt dot kantor at gmail dot com @hholzgra: Your only-coerce-on-failure proposal would not solve this issue. Assuming that by "fail" you mean "the comparison evaluates to false", the strings would end up being coerced anyway (since they are indeed different), they'd become identical floats, and things would be the same as they are now. If I misunderstood what you meant by "fail", then we'd lose "1" == "1.0", which I don't think is something that can (or should) happen. [2012-04-12 22:45:28] erowid at inbox dot lv I want to marry it, lather this thread up, and have my way with it. I want to have little threads everywhere that are as funny as this xD [2012-04-12 22:14:36] chx1975 at gmail dot com Now, while I can understand why PHP chooses "1" == 1 (HTML, sure) I am not too sure how is that relevant when both sides are strings?? I am not quite sure why the strings "1" and "1.0" would need to be ==. Just because "1" == 1 and "1.0" == 1 does not mean "1" == "1.0". It's not transitive! Compare FALSE == 0; 0 == 'x'; 'x' == TRUE -- if it would be transitive then FALSE == TRUE, surely you don't want that. [2012-04-12 21:23:40] vinny_182 at hotmail dot com Equality is equality and neither string or numeric representations of the value are equal. The bug IMO is in the conversion from string to float, the conversion has failed but a valid value is still returned. That's just plain wrong. If you wrote unit tests for string to float conversions and this was the input you would expect it to return a null value or throw an exception. [2012-04-12 21:02:06] c at hotmail dot com "In the majority of cases when dealing with HTTP requests and database results, which is what PHP deals with most, the loose comparison makes life easiest on the developer." By 'the developer' I assume you mean people who can't type (string) or (int) ? No other language has this issue because they aren't designed around programmers who do not really understand how to program. Please make the developer's life easier by making comparisons make sense. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54547 -- Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
