[PHP-BUG] Req #60789 [NEW]: pow() uses floats if one argument is a float
From: Operating system: *nix PHP version: trunk-SVN-2012-01-18 (SVN) Package: Math related Bug Type: Feature/Change Request Bug description:pow() uses floats if one argument is a float Description: I ran into an issue with pow() that causes it to lose precision on 64 bit platforms if one or more of the arguments is a float. I've attached a patch that fixes this by checking if both arguments are exactly representable as an integer, and if so converting to an integer. This attempts to retain as much precision as possible by letting the result be an exact representation where possible. Additionally, the patch fixes a tested-for-bug on 64 bit platforms where: pow(-9.2233720368548E+18, 9223372036854775807) == INF when it should be -INF. Test script: --- var_dump((int) (pow(2, (float) 55) - 1)); Expected result: int(36028797018963967) Actual result: -- int(36028797018963968) -- Edit bug report at https://bugs.php.net/bug.php?id=60789&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60789&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60789&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60789&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60789&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60789&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60789&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60789&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60789&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60789&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60789&r=support Expected behavior: https://bugs.php.net/fix.php?id=60789&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60789&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60789&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60789&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60789&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60789&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60789&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60789&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60789&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60789&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60789&r=mysqlcfg
Req->Bug #60789 [Opn]: pow() uses floats if one argument is a float
Edit report at https://bugs.php.net/bug.php?id=60789&edit=1 ID: 60789 User updated by:ircmaxell at gmail dot com Reported by:ircmaxell at gmail dot com Summary:pow() uses floats if one argument is a float Status: Open -Type: Feature/Change Request +Type: Bug Package:Math related Operating System: *nix PHP Version:trunk-SVN-2012-01-18 (SVN) Block user comment: N Private report: N New Comment: Changing type to bug, as this fixes the implementation to correspond to the docs: http://us3.php.net/pow Specifically: "base raised to the power of exp. If the result can be represented as integer it will be returned as type integer, else it will be returned as type float." Previous Comments: [2012-01-18 13:00:30] ircmaxell at gmail dot com Description: I ran into an issue with pow() that causes it to lose precision on 64 bit platforms if one or more of the arguments is a float. I've attached a patch that fixes this by checking if both arguments are exactly representable as an integer, and if so converting to an integer. This attempts to retain as much precision as possible by letting the result be an exact representation where possible. Additionally, the patch fixes a tested-for-bug on 64 bit platforms where: pow(-9.2233720368548E+18, 9223372036854775807) == INF when it should be -INF. Test script: --- var_dump((int) (pow(2, (float) 55) - 1)); Expected result: int(36028797018963967) Actual result: -- int(36028797018963968) -- Edit this bug report at https://bugs.php.net/bug.php?id=60789&edit=1
Req #47802 [Com]: PDO_MYSQL doesn't use the charset parameter
Edit report at http://bugs.php.net/bug.php?id=47802&edit=1
ID: 47802
Comment by: ircmaxell at gmail dot com
Reported by:disbursement at dublin dot com
Summary:PDO_MYSQL doesn't use the charset parameter
Status: Closed
Type: Feature/Change Request
Package:MySQL related
Operating System: all
PHP Version:5.2.9
Assigned To:kalle
Block user comment: N
Private report: N
New Comment:
Re-opening this as it has security implications for 5.2.x. It should be
backported and re-released as a security fix for 5.2.x.
As it stands now, PDO::quote() does not protect against security
vulnerabilities
without the ability to set the character set in the C api. 5.3.6 closes
this
hole when supplied with the optional charset parameter (by appropriately
setting
the character set). However this will need to be expressed in the
documentation
(I will file another issue on this topic).
Proof Of Concept Code:
$dsn = 'mysql:dbname=INFORMATION_SCHEMA;host=127.0.0.1;charset=GBK';
$pdo = new PDO($dsn, $user, $pass);
$pdo->exec('SET NAMES GBK');
$string = chr(0xbf) . chr(0x27) . ' OR 1 = 1; /*';
$sql = "SELECT TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME LIKE ".$pdo->quote($string).";";
$stmt = $pdo->query($sql);
var_dump($stmt->rowCount());
Expected: int(0)
Actual: the number of tables on the server
Previous Comments:
[2011-01-17 11:46:00] ka...@php.net
Will appear in PHP 5.3.6 :)
[2011-01-17 10:54:23] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307529
Log: MFT: Implemented FR #47802 (Support for setting character sets in
DSN strings)
[2011-01-07 18:18:31] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307228
Log: Added test case for #47802 and fixed macro name after the move to
mysql_options()
[2011-01-07 15:40:32] ka...@php.net
Implemented in trunk for now
[2011-01-07 15:39:58] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307224
Log: Implemented FR #47802, support for character sets in DSN strings
for PDO_MYSQL
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=47802
--
Edit this bug report at http://bugs.php.net/bug.php?id=47802&edit=1
Req #47802 [Com]: PDO_MYSQL doesn't use the charset parameter
Edit report at http://bugs.php.net/bug.php?id=47802&edit=1
ID: 47802
Comment by: ircmaxell at gmail dot com
Reported by:disbursement at dublin dot com
Summary:PDO_MYSQL doesn't use the charset parameter
Status: To be documented
Type: Feature/Change Request
Package:MySQL related
Operating System: all
PHP Version:5.2.9
Block user comment: N
Private report: N
New Comment:
I won't argue the decision, but I'd like to clarify one point. Right
now, in
5.2.x (and <=5.3.5) it's impossible to write a secure query using
PDO::quote. So
if you use another character set, it would automatically make all code
vulnerable
to SQL Injection (with no built-in method to fix it). So that leaves
existing
the code 3 options: Switch to MySQLi, Implement their own quoting
mechanism, or
switch to prepared statements (the best solution). But as it stands,
the API
does not deliver its promise.
Just an observation...
Previous Comments:
[2011-04-19 01:07:20] johan...@php.net
If a developer shots himself it is noting we can prevent. Tis does not
justify a security release of PHP as the only one who can exploit this
is the one writing code ...
This should however be made clear in the documentation: Executing SET
NAMES doesn't tell anything to the client library (libmysql / mysqlnd
used by PHP) so they can't do proper encoding. Therefore only Latin 1,
Utf-8 and other encodings using lower 7 bits in an ASCII compatible way
can be used safely. For other encodings the mentioned option, introduced
later in 5.3.6 should be used.
[2011-04-18 22:38:48] col...@php.net
Re-opening because of 5_2 backport request by some user.
--------
[2011-04-18 22:34:03] ircmaxell at gmail dot com
Re-opening this as it has security implications for 5.2.x. It should be
backported and re-released as a security fix for 5.2.x.
As it stands now, PDO::quote() does not protect against security
vulnerabilities
without the ability to set the character set in the C api. 5.3.6 closes
this
hole when supplied with the optional charset parameter (by appropriately
setting
the character set). However this will need to be expressed in the
documentation
(I will file another issue on this topic).
Proof Of Concept Code:
$dsn = 'mysql:dbname=INFORMATION_SCHEMA;host=127.0.0.1;charset=GBK';
$pdo = new PDO($dsn, $user, $pass);
$pdo->exec('SET NAMES GBK');
$string = chr(0xbf) . chr(0x27) . ' OR 1 = 1; /*';
$sql = "SELECT TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME LIKE ".$pdo->quote($string).";";
$stmt = $pdo->query($sql);
var_dump($stmt->rowCount());
Expected: int(0)
Actual: the number of tables on the server
[2011-01-17 11:46:00] ka...@php.net
Will appear in PHP 5.3.6 :)
[2011-01-17 10:54:23] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307529
Log: MFT: Implemented FR #47802 (Support for setting character sets in
DSN strings)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=47802
--
Edit this bug report at http://bugs.php.net/bug.php?id=47802&edit=1
[PHP-BUG] Bug #55168 [NEW]: mcrypt_create_iv uses E_ERROR on Win and E_WARNING on *nix
From: Operating system: Windows PHP version: 5.4SVN-2011-07-09 (SVN) Package: mcrypt related Bug Type: Bug Bug description:mcrypt_create_iv uses E_ERROR on Win and E_WARNING on *nix Description: If you call mcrypt_create_iv with either the MCRYPT_DEV_RANDOM or MCRYPT_DEV_URANDOM constants, and it cannot generate enough data, it issues an E_ERROR fatal error. However, on linux when the same situation it will just issue an E_WARNING. I suggest that it should be changed from an E_ERROR to an E_WARNING on Windows (as it certainly is recoverable). See: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/mcrypt/mcrypt.c? revision=311033&view=markup Specifically lines 1397 and 1422 -- Edit bug report at https://bugs.php.net/bug.php?id=55168&edit=1 -- Try a snapshot (PHP 5.2): https://bugs.php.net/fix.php?id=55168&r=trysnapshot52 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55168&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55168&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55168&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55168&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55168&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55168&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55168&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55168&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55168&r=support Expected behavior: https://bugs.php.net/fix.php?id=55168&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55168&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55168&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55168&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55168&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55168&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55168&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55168&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55168&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55168&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55168&r=mysqlcfg Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55168&r=trysnapshot54
