Req #50434 [Com]: add string functions str_startswith and str_endswith for convenience
Edit report at https://bugs.php.net/bug.php?id=50434edit=1
ID: 50434
Comment by: olafvdspek at gmail dot com
Reported by:mail at daniel-faber dot de
Summary:add string functions str_startswith and str_endswith
for convenience
Status: Analyzed
Type: Feature/Change Request
Package:Strings related
PHP Version:5.2.11
Block user comment: N
Private report: N
New Comment:
Please?
http://stackoverflow.com/questions/834303/php-startswith-and-endswith-functions
Requests for these functions come up again and again.
Case insensitive variants might be useful too.
Previous Comments:
[2012-08-20 21:01:08] ajf at ajf dot me
I would also like to see this. It's very handy for string checking. Both Python
and C# have such a method. (accompanied by Python's in, it's very handy) For
brevity I'd prefer startswith() and endswith(), however.
I think I'll write a patch :)
[2009-12-10 13:19:38] mail at daniel-faber dot de
Possible problems with the above corner cases are not the main reasons why I
requested these functions. Even if I know this corner cases will not occur in
my application I'll prefer str_startswith($s, $p) to substr($s, 0, strlen($p))
== $p because it's shorter and easier to read.
This functionality is so often needed and when you need it, you have do use the
substr expression or define you own str_startswith function. So why not adding
it to the PHP core since it's such a basic thing...
[2009-12-10 00:58:48] mail at daniel-faber dot de
rasmus, this is right in nearly all cases, but here are some corner cases where
your code fails:
startswith('', '0')
should be false, but your code gives true
reason: substr('', 0, 1) is false
false == '0' is true
if you try to fix this by replacing == with ===, another corner case will fail:
startswith('', '')
should be true, but will be false
reason: substr('', 0, 0) is false
false === '' is false
this seems to work in all cases:
function str_startswith($string, $prefix) {
if (strlen($string) strlen($prefix))
return false;
return substr($string, 0, strlen($prefix)) == $prefix;
}
similar for endswith:
endswith('', '0') should be false, but is true
endswith('test', '') should be true, but is false
this seems to work in all cases:
function str_endswith($string, $suffix) {
$suffixLength = strlen($suffix);
if ($suffixLength == 0)
return true;
if (strlen($string) $suffixLength)
return false;
return substr($string, -$suffixLength) == $suffix;
}
[2009-12-09 23:48:49] ras...@php.net
Isn't it super trivial given the way substr works in PHP?
startswith:
substr($haystack,0,strlen($prefix)) == $prefix
endswith:
substr($haystack,-strlen($suffix)) == $suffix
Usually we add things to core that can't be done with a single trivial
call in PHP. The only thing you save is the strlen call, and you can
hardcode that to avoid it.
[2009-12-09 23:39:58] mail at daniel-faber dot de
Description:
Please add these two string functions for convenience:
boolean str_startswith($string, $prefix)
// true if $string starts with $prefix, false otherwise
boolean str_endswith($string, $suffix)
// true if $string ends with $suffix, false otherwise
Of course one can easily write these functions in PHP, but having them in the
PHP core would be nice. You find them in other languages too:
Java: string.startsWith(prefix) and string.endsWith(suffix)
Python: string.startswith(prefix) and string.endswith(suffix)
--
Edit this bug report at https://bugs.php.net/bug.php?id=50434edit=1
[PHP-BUG] Req #60368 [NEW]: pg_query_params() like function
From: Operating system: * PHP version: 5.4.0RC1 Package: MySQLi related Bug Type: Feature/Change Request Bug description:pg_query_params() like function Description: This is a great function. Could you add a MySQL variant? http://php.net/manual/en/function.pg-query-params.php It might be easier to pass the params as normal params instead of as an array. -- Edit bug report at https://bugs.php.net/bug.php?id=60368edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60368r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60368r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60368r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60368r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60368r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60368r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60368r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60368r=needscript Try newer version: https://bugs.php.net/fix.php?id=60368r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60368r=support Expected behavior: https://bugs.php.net/fix.php?id=60368r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60368r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60368r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60368r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60368r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60368r=dst IIS Stability: https://bugs.php.net/fix.php?id=60368r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60368r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60368r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60368r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60368r=mysqlcfg
[PHP-BUG] Req #60311 [NEW]: Allow multiple arguments instead of array
From: Operating system: * PHP version: 5.4.0RC1 Package: PostgreSQL related Bug Type: Feature/Change Request Bug description:Allow multiple arguments instead of array Description: This is a great function, but it could be even simpler. Is it possible to use multiple arguments instead of the array? See the test script. http://php.net/manual/en/function.pg-query-params.php Test script: --- $result = pg_query_params($dbconn, 'SELECT * FROM shops WHERE name = $1 and age = $2', array(Joe's Widgets, 42)); $result = pg_query_params($dbconn, 'SELECT * FROM shops WHERE name = $1 and age = $2', Joe's Widgets, 42); -- Edit bug report at https://bugs.php.net/bug.php?id=60311edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60311r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60311r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60311r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60311r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60311r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60311r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60311r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60311r=needscript Try newer version: https://bugs.php.net/fix.php?id=60311r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60311r=support Expected behavior: https://bugs.php.net/fix.php?id=60311r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60311r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60311r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60311r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60311r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60311r=dst IIS Stability: https://bugs.php.net/fix.php?id=60311r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60311r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60311r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60311r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60311r=mysqlcfg
Req #46202 [Com]: Avoid SQL injection by design
Edit report at https://bugs.php.net/bug.php?id=46202edit=1 ID: 46202 Comment by: olafvdspek at gmail dot com Reported by:olafvdspek at gmail dot com Summary:Avoid SQL injection by design Status: Bogus Type: Feature/Change Request Package:*General Issues PHP Version:5.2.6 Block user comment: N Private report: N New Comment: So mysql_query() is deprecated? The mysql_query() page doesn't mention mysqli or PDO at all, wouldn't it be good to mention those if those are indeed the recommended way? Previous Comments: [2011-07-07 03:32:13] ahar...@php.net Given the existence of both PDO and mysqli, I don't think anything Scott said three years ago has changed. [2011-07-06 07:24:37] olafvdspek at gmail dot com SQL injections are still happening today and in a lot of cases PHP is involved. In my opinion it'd not be so hard to implement this feature request. It'd make a lot of people happy! Could you reconsider? [2008-09-30 10:19:04] olafvdspek at gmail dot com Sorry, but your problem does not imply a bug in PHP itself. Guess why I used category: feature/change request. ;) I'm aware of mysqli_prepare, but it's not what I requested, although the syntax might look similar. mysqli_prepare is harder to use than mysql_query, instead of easier. That's no good... [2008-09-30 10:14:45] scott...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. mysqli_prepare() already exists. [2008-09-30 09:26:54] olafvdspek at gmail dot com Description: The standard mysql_query function is very prone to abuse. Could a function be added that's safer? Like, for example: mysql_query_safe(insert into T (A, B, C) values (?, ?, ?), $a, $b, $c); The function would be a bit like sprintf, except it would automatically call mysql_real_escape_string on all non-int arguments and enclose them in single quotes. Safe types like int would not receive this treatment. Reproduce code: --- mysql_query(insert into T (A, B, C) values (?, ?, ?), $a, $b, $c); Expected result: No SQL injection vulnerability Actual result: -- SQL injection vulnerability -- Edit this bug report at https://bugs.php.net/bug.php?id=46202edit=1
Req #46202 [Com]: Avoid SQL injection by design
Edit report at https://bugs.php.net/bug.php?id=46202edit=1 ID: 46202 Comment by: olafvdspek at gmail dot com Reported by:olafvdspek at gmail dot com Summary:Avoid SQL injection by design Status: Bogus Type: Feature/Change Request Package:Feature/Change Request PHP Version:5.2.6 Block user comment: N Private report: N New Comment: SQL injections are still happening today and in a lot of cases PHP is involved. In my opinion it'd not be so hard to implement this feature request. It'd make a lot of people happy! Could you reconsider? Previous Comments: [2008-09-30 10:19:04] olafvdspek at gmail dot com Sorry, but your problem does not imply a bug in PHP itself. Guess why I used category: feature/change request. ;) I'm aware of mysqli_prepare, but it's not what I requested, although the syntax might look similar. mysqli_prepare is harder to use than mysql_query, instead of easier. That's no good... [2008-09-30 10:14:45] scott...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. mysqli_prepare() already exists. [2008-09-30 09:26:54] olafvdspek at gmail dot com Description: The standard mysql_query function is very prone to abuse. Could a function be added that's safer? Like, for example: mysql_query_safe(insert into T (A, B, C) values (?, ?, ?), $a, $b, $c); The function would be a bit like sprintf, except it would automatically call mysql_real_escape_string on all non-int arguments and enclose them in single quotes. Safe types like int would not receive this treatment. Reproduce code: --- mysql_query(insert into T (A, B, C) values (?, ?, ?), $a, $b, $c); Expected result: No SQL injection vulnerability Actual result: -- SQL injection vulnerability -- Edit this bug report at https://bugs.php.net/bug.php?id=46202edit=1
Bug #51920 [Bgs]: ip2long result depends on platform
Edit report at http://bugs.php.net/bug.php?id=51920edit=1 ID: 51920 User updated by: olafvdspek at gmail dot com Reported by: olafvdspek at gmail dot com Summary: ip2long result depends on platform Status: Bogus Type: Bug Package: Network related Operating System: Debian x64 PHP Version: 5.3.2 New Comment: Like I said before, I know what signed and unsigned shorts, ints, longs and long longs are. Previous Comments: [2010-05-27 08:25:49] m...@php.net Please read up on that topic and stop complaining about nothing. You may start here or anywhere else: http://en.wikipedia.org/wiki/Integer_%28computer_science%29 [2010-05-26 23:28:15] olafvdspek at gmail dot com Then just return the negative value. [2010-05-26 23:26:23] johan...@php.net This would be a different binary representation, which breaks binary math, which people often do with IP addresses. [2010-05-26 17:16:53] olafvdspek at gmail dot com Returning -107373295 on x64 would make it consistent with x86. But people might prefer 3221234342, in which case it could be returned as a string. [2010-05-26 17:13:14] sala...@php.net So what are you requesting? That ip2long returns a string representation of the number, or a float? Of which value 3221234342 or -107373295? 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=51920 -- Edit this bug report at http://bugs.php.net/bug.php?id=51920edit=1
[PHP-BUG] Bug #51920 [NEW]: ip2long result depends on platform
From:
Operating system: Debian x64
PHP version: 5.3.2
Package: Network related
Bug Type: Bug
Bug description:ip2long result depends on platform
Description:
The result of ip2long depends on the plaform. It shouldn't.
Test script:
---
?php
echo ip2long('192.0.34.166');
x86: -1073732954
x64: 3221234342
Expected result:
-1073732954
Actual result:
--
3221234342
--
Edit bug report at http://bugs.php.net/bug.php?id=51920edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51920r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51920r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=51920r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=51920r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51920r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51920r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51920r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51920r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51920r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51920r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51920r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51920r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51920r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51920r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51920r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51920r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51920r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51920r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51920r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51920r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51920r=mysqlcfg
Bug #51920 [Bgs]: ip2long result depends on platform
Edit report at http://bugs.php.net/bug.php?id=51920edit=1
ID: 51920
User updated by: olafvdspek at gmail dot com
Reported by: olafvdspek at gmail dot com
Summary: ip2long result depends on platform
Status: Bogus
Type: Bug
Package: Network related
Operating System: Debian x64
PHP Version: 5.3.2
New Comment:
I know how to print an uint, that's not my question!
Previous Comments:
[2010-05-26 12:42:49] paj...@php.net
See the example in the PHP manual to know how to print out unsigned
integer.
[2010-05-26 12:39:32] olafvdspek at gmail dot com
Description:
The result of ip2long depends on the plaform. It shouldn't.
Test script:
---
?php
echo ip2long('192.0.34.166');
x86: -1073732954
x64: 3221234342
Expected result:
-1073732954
Actual result:
--
3221234342
--
Edit this bug report at http://bugs.php.net/bug.php?id=51920edit=1
Bug #51920 [Bgs]: ip2long result depends on platform
Edit report at http://bugs.php.net/bug.php?id=51920edit=1
ID: 51920
User updated by: olafvdspek at gmail dot com
Reported by: olafvdspek at gmail dot com
Summary: ip2long result depends on platform
Status: Bogus
Type: Bug
Package: Network related
Operating System: Debian x64
PHP Version: 5.3.2
New Comment:
I'm asking for ip2long to return the same (negative) values on all
platforms.
Previous Comments:
[2010-05-26 13:10:26] paj...@php.net
So what are you asking then? That's exactly what you are experiencing.
There is no bug.
[2010-05-26 12:45:09] olafvdspek at gmail dot com
I know how to print an uint, that's not my question!
[2010-05-26 12:42:49] paj...@php.net
See the example in the PHP manual to know how to print out unsigned
integer.
[2010-05-26 12:39:32] olafvdspek at gmail dot com
Description:
The result of ip2long depends on the plaform. It shouldn't.
Test script:
---
?php
echo ip2long('192.0.34.166');
x86: -1073732954
x64: 3221234342
Expected result:
-1073732954
Actual result:
--
3221234342
--
Edit this bug report at http://bugs.php.net/bug.php?id=51920edit=1
Bug #51920 [Bgs]: ip2long result depends on platform
Edit report at http://bugs.php.net/bug.php?id=51920edit=1 ID: 51920 User updated by: olafvdspek at gmail dot com Reported by: olafvdspek at gmail dot com Summary: ip2long result depends on platform Status: Bogus Type: Bug Package: Network related Operating System: Debian x64 PHP Version: 5.3.2 New Comment: I know perfectly well what an unsigned int is. Previous Comments: [2010-05-26 15:06:10] paj...@php.net So no, you don't know what an unsigned integer value is. Please ask support in one of the numerous php support channels. [2010-05-26 13:11:53] olafvdspek at gmail dot com I'm asking for ip2long to return the same (negative) values on all platforms. [2010-05-26 13:10:26] paj...@php.net So what are you asking then? That's exactly what you are experiencing. There is no bug. [2010-05-26 12:45:09] olafvdspek at gmail dot com I know how to print an uint, that's not my question! [2010-05-26 12:42:49] paj...@php.net See the example in the PHP manual to know how to print out unsigned integer. 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=51920 -- Edit this bug report at http://bugs.php.net/bug.php?id=51920edit=1
Bug #51920 [Bgs]: ip2long result depends on platform
Edit report at http://bugs.php.net/bug.php?id=51920edit=1 ID: 51920 User updated by: olafvdspek at gmail dot com Reported by: olafvdspek at gmail dot com Summary: ip2long result depends on platform Status: Bogus Type: Bug Package: Network related Operating System: Debian x64 PHP Version: 5.3.2 New Comment: Returning -107373295 on x64 would make it consistent with x86. But people might prefer 3221234342, in which case it could be returned as a string. Previous Comments: [2010-05-26 17:13:14] sala...@php.net So what are you requesting? That ip2long returns a string representation of the number, or a float? Of which value 3221234342 or -107373295? [2010-05-26 15:25:29] olafvdspek at gmail dot com I know perfectly well what an unsigned int is. [2010-05-26 15:06:10] paj...@php.net So no, you don't know what an unsigned integer value is. Please ask support in one of the numerous php support channels. [2010-05-26 13:11:53] olafvdspek at gmail dot com I'm asking for ip2long to return the same (negative) values on all platforms. [2010-05-26 13:10:26] paj...@php.net So what are you asking then? That's exactly what you are experiencing. There is no bug. 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=51920 -- Edit this bug report at http://bugs.php.net/bug.php?id=51920edit=1
Bug #51920 [Bgs]: ip2long result depends on platform
Edit report at http://bugs.php.net/bug.php?id=51920edit=1 ID: 51920 User updated by: olafvdspek at gmail dot com Reported by: olafvdspek at gmail dot com Summary: ip2long result depends on platform Status: Bogus Type: Bug Package: Network related Operating System: Debian x64 PHP Version: 5.3.2 New Comment: Then just return the negative value. Previous Comments: [2010-05-26 23:26:23] johan...@php.net This would be a different binary representation, which breaks binary math, which people often do with IP addresses. [2010-05-26 17:16:53] olafvdspek at gmail dot com Returning -107373295 on x64 would make it consistent with x86. But people might prefer 3221234342, in which case it could be returned as a string. [2010-05-26 17:13:14] sala...@php.net So what are you requesting? That ip2long returns a string representation of the number, or a float? Of which value 3221234342 or -107373295? [2010-05-26 15:25:29] olafvdspek at gmail dot com I know perfectly well what an unsigned int is. [2010-05-26 15:06:10] paj...@php.net So no, you don't know what an unsigned integer value is. Please ask support in one of the numerous php support 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 http://bugs.php.net/bug.php?id=51920 -- Edit this bug report at http://bugs.php.net/bug.php?id=51920edit=1
#46717 [NEW]: Crash in php_mysqli.dll with MySQL 5.1 DLL
From: olafvdspek at gmail dot com Operating system: Windows 2003 PHP version: 5.2.6 PHP Bug Type: MySQLi related Bug description: Crash in php_mysqli.dll with MySQL 5.1 DLL Description: When I use libmysql.dll from MySQL 5.1, PHP crashes. When I use the one from 5.0, it works fine. The crash occurs when I access phpMyAdmin. Faulting application httpd.exe, version 2.2.10.0, faulting module php_mysqli.dll, version 5.2.6.6, fault address 0x2beb. Windows 2003, Apache 2.2.10, PHP 5.2.6, MySQL 5.1.30 Reproduce code: --- Use phpMyAdmin, I don't have a reduced test case (yet). Expected result: No crash. Actual result: -- Crash. -- Edit bug report at http://bugs.php.net/?id=46717edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46717r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46717r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46717r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46717r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46717r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46717r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46717r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46717r=needscript Try newer version: http://bugs.php.net/fix.php?id=46717r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46717r=support Expected behavior: http://bugs.php.net/fix.php?id=46717r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46717r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46717r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46717r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46717r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46717r=dst IIS Stability: http://bugs.php.net/fix.php?id=46717r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46717r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46717r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46717r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46717r=mysqlcfg
#46717 [Bgs]: -
ID: 46717 User updated by: olafvdspek at gmail dot com -Summary: Crash in php_mysqli.dll with MySQL 5.1 DLL Reported By: olafvdspek at gmail dot com Status: Bogus Bug Type: MySQLi related Operating System: Windows 2003 PHP Version: 5.2.6 Assigned To: pajoye New Comment: If I delete the 5.1 DLL from windows/system32 Apache/PHP says it can't find libmysql.dll, although it is in the PHP dir. Previous Comments: [2008-11-29 14:07:22] [EMAIL PROTECTED] Use only the DLLs provided with our releases. MySql's DLLs are not compatible with php builds (different crt). [2008-11-29 13:44:23] olafvdspek at gmail dot com Description: When I use libmysql.dll from MySQL 5.1, PHP crashes. When I use the one from 5.0, it works fine. The crash occurs when I access phpMyAdmin. Faulting application httpd.exe, version 2.2.10.0, faulting module php_mysqli.dll, version 5.2.6.6, fault address 0x2beb. Windows 2003, Apache 2.2.10, PHP 5.2.6, MySQL 5.1.30 Reproduce code: --- Use phpMyAdmin, I don't have a reduced test case (yet). Expected result: No crash. Actual result: -- Crash. -- Edit this bug report at http://bugs.php.net/?id=46717edit=1
#46717 [Bgs]: Crash in php_mysqli.dll with MySQL 5.1 DLL
ID: 46717 User updated by: olafvdspek at gmail dot com -Summary: - Reported By: olafvdspek at gmail dot com Status: Bogus Bug Type: MySQLi related Operating System: Windows 2003 PHP Version: 5.2.6 Assigned To: pajoye New Comment: Hmm, somehow the summary got lost. Previous Comments: [2008-11-29 14:14:07] olafvdspek at gmail dot com If I delete the 5.1 DLL from windows/system32 Apache/PHP says it can't find libmysql.dll, although it is in the PHP dir. [2008-11-29 14:07:22] [EMAIL PROTECTED] Use only the DLLs provided with our releases. MySql's DLLs are not compatible with php builds (different crt). [2008-11-29 13:44:23] olafvdspek at gmail dot com Description: When I use libmysql.dll from MySQL 5.1, PHP crashes. When I use the one from 5.0, it works fine. The crash occurs when I access phpMyAdmin. Faulting application httpd.exe, version 2.2.10.0, faulting module php_mysqli.dll, version 5.2.6.6, fault address 0x2beb. Windows 2003, Apache 2.2.10, PHP 5.2.6, MySQL 5.1.30 Reproduce code: --- Use phpMyAdmin, I don't have a reduced test case (yet). Expected result: No crash. Actual result: -- Crash. -- Edit this bug report at http://bugs.php.net/?id=46717edit=1
#46355 [NEW]: Query logger
From: olafvdspek at gmail dot com
Operating system: *
PHP version: 6CVS-2008-10-21 (CVS)
PHP Bug Type: Feature/Change Request
Bug description: Query logger
Description:
Hi,
Could you add a (MySQL) query logger? It'd log each query, including the
duration and number of rows affected. This is very useful to diagnose slow
pages.
See below for an idea of what interface could be provided.
Reproduce code:
---
mysql_log_queries(true);
mysql_query(select * from T);
$a = mysql_get_log();
foreach ($a as $row)
{
printf(%.1f ms - %d rows - %s, $row['duration'],
$row['affected_rows'], htmlspecialchars($row['query']));
}
Expected result:
-
Actual result:
--
-
--
Edit bug report at http://bugs.php.net/?id=46355edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46355r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46355r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46355r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=46355r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=46355r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=46355r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=46355r=needscript
Try newer version:http://bugs.php.net/fix.php?id=46355r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=46355r=support
Expected behavior:http://bugs.php.net/fix.php?id=46355r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46355r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46355r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=46355r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46355r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=46355r=dst
IIS Stability:http://bugs.php.net/fix.php?id=46355r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=46355r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=46355r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=46355r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=46355r=mysqlcfg
#46202 [NEW]: Avoid SQL injection by design
From: olafvdspek at gmail dot com Operating system: PHP version: 5.2.6 PHP Bug Type: Feature/Change Request Bug description: Avoid SQL injection by design Description: The standard mysql_query function is very prone to abuse. Could a function be added that's safer? Like, for example: mysql_query_safe(insert into T (A, B, C) values (?, ?, ?), $a, $b, $c); The function would be a bit like sprintf, except it would automatically call mysql_real_escape_string on all non-int arguments and enclose them in single quotes. Safe types like int would not receive this treatment. Reproduce code: --- mysql_query(insert into T (A, B, C) values (?, ?, ?), $a, $b, $c); Expected result: No SQL injection vulnerability Actual result: -- SQL injection vulnerability -- Edit bug report at http://bugs.php.net/?id=46202edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46202r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46202r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46202r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46202r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46202r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46202r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46202r=needscript Try newer version:http://bugs.php.net/fix.php?id=46202r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46202r=support Expected behavior:http://bugs.php.net/fix.php?id=46202r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46202r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46202r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46202r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46202r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46202r=dst IIS Stability:http://bugs.php.net/fix.php?id=46202r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46202r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46202r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46202r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46202r=mysqlcfg
#46202 [Bgs]: Avoid SQL injection by design
ID: 46202 User updated by: olafvdspek at gmail dot com Reported By: olafvdspek at gmail dot com Status: Bogus Bug Type:Feature/Change Request PHP Version: 5.2.6 New Comment: Sorry, but your problem does not imply a bug in PHP itself. Guess why I used category: feature/change request. ;) I'm aware of mysqli_prepare, but it's not what I requested, although the syntax might look similar. mysqli_prepare is harder to use than mysql_query, instead of easier. That's no good... Previous Comments: [2008-09-30 10:14:45] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. mysqli_prepare() already exists. [2008-09-30 09:26:54] olafvdspek at gmail dot com Description: The standard mysql_query function is very prone to abuse. Could a function be added that's safer? Like, for example: mysql_query_safe(insert into T (A, B, C) values (?, ?, ?), $a, $b, $c); The function would be a bit like sprintf, except it would automatically call mysql_real_escape_string on all non-int arguments and enclose them in single quotes. Safe types like int would not receive this treatment. Reproduce code: --- mysql_query(insert into T (A, B, C) values (?, ?, ?), $a, $b, $c); Expected result: No SQL injection vulnerability Actual result: -- SQL injection vulnerability -- Edit this bug report at http://bugs.php.net/?id=46202edit=1
#44252 [NEW]: ? : evaluation bug
From: OlafvdSpek at GMail dot Com Operating system: Linux, Windows PHP version: 5.2.5 PHP Bug Type: *General Issues Bug description: ? : evaluation bug Description: The following code echoes 3 while it should echo 2. It should be evaluated as 1 ? 2 : (0 ? 3 : 4). I've no idea how PHP comes up with 3. Reproduce code: --- echo 1 ? 2 : 0 ? 3 : 4; Expected result: 2 Actual result: -- 3 -- Edit bug report at http://bugs.php.net/?id=44252edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44252r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44252r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44252r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44252r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44252r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44252r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44252r=needscript Try newer version:http://bugs.php.net/fix.php?id=44252r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44252r=support Expected behavior:http://bugs.php.net/fix.php?id=44252r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44252r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44252r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44252r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44252r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44252r=dst IIS Stability:http://bugs.php.net/fix.php?id=44252r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44252r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44252r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44252r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44252r=mysqlcfg
#44252 [Bgs]: ? : evaluation bug
ID: 44252 User updated by: OlafvdSpek at GMail dot Com Reported By: OlafvdSpek at GMail dot Com Status: Bogus Bug Type: *General Issues Operating System: Linux, Windows PHP Version: 5.2.5 New Comment: Ah, so it's evaluated as (1 ? 2 : 0) ? 3 : 4 Nice, very nice. :( Previous Comments: [2008-02-26 12:47:31] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This is documented. See the example#3: http://docs.php.net/manual/en/language.operators.comparison.php#language.operators.comparison.ternary [2008-02-26 12:35:20] OlafvdSpek at GMail dot Com Description: The following code echoes 3 while it should echo 2. It should be evaluated as 1 ? 2 : (0 ? 3 : 4). I've no idea how PHP comes up with 3. Reproduce code: --- echo 1 ? 2 : 0 ? 3 : 4; Expected result: 2 Actual result: -- 3 -- Edit this bug report at http://bugs.php.net/?id=44252edit=1
#43610 [Com]: fastcgi socket dies on high concurrency
ID: 43610 Comment by: olafvdspek at gmail dot com Reported By: oliver at realtsp dot com Status: Open Bug Type: CGI related Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Since the parent process manages this queue Eh, are you sure it does? As far as I know that's not true. Previous Comments: [2007-12-23 11:31:54] oliver at realtsp dot com @olafvdspek at gmail dot com That is not in keeping with the FastCGI spec: # FCGI_OVERLOADED: rejecting a new request. This happens when the application runs out of some resource, e.g. database connections. The situation I am talking about here is a severely overloaded condition. ie all php worker (child) processes are already busy and there is a queue of, in my case, an additional 200+ connections. My suggestion is that the php parent process allows a max_fastcgi_queue of say 200 and then rejects further connections with FCGI_OVERLOADED. Since the parent process manages this queue it should its size and it should be be easy to place a max limit on that size. The limit could be configured in php.ini. [2007-12-22 15:10:55] olafvdspek at gmail dot com Could you explain or perhaps review PHP's behaviour under overloaded conditions. I'm no PHP developer and haven't looked at the code, but my guess: A PHP process has C children, each being able to handle one connection. When that connection is closed, it'll do an accept() to handle a new connection. When a web server opens more than C connections, those will not be accepted until an existing connection is closed, which may take a long time. So a web server should never open more than C connections to one PHP process. [2007-12-17 13:05:41] oliver at realtsp dot com Actually.. It turns out that the php parent is not dead at all. Even with stable 5.2.5 (rather than 5.2-latest) if you setup the fastcgi server to be started separately from lighty ie with lighty config like this: fastcgi.server = ( .php = ( localhost = ( socket = /tmp/php-fastcgi.sock ) ) ) and the use spawn_fcgi to start the php fcgi server manually. Then all behaves as expected. ie you get some (not all!!) 500s while the overload condition exists and when the load drops away you get all normal 200 responses again. ie elastic/tolerant performance as hoped for. After some investigation into the the lighty source it turns out that lighty is confused by the fact that PHP just fails to respond (ie timeout) rather than returning FCGI_OVERLOADED. refer to this: http://bugs.php.net/bug.php?id=39809 where dimitry said: PHP cannot return FCGI_OVERLOADED, because all PHP processes are busy and nobody accepts new connection. The only way to detect this situation - use connection timeout. lighty however is sticking to the fastcgi spec and expecting the php parent to be in shutdown mode (ie its PID to dissappear) when it does not respond (after which it would then respawn a new parent). But because the PHP parent is just busy and not actually shutting down, the PID never dissappears and lighty gets stuck in a loop. I have posted a workaround involving starting PHP separately here: http://trac.lighttpd.net/trac/ticket/1488 which also proposes a patch to deal with PHP's non-standard behaviour regarding FCGI_OVERLOADED. However, the fundamental problem remains: It is very difficult for a FASTCGI client to determine what is going on and therefore what to do when php just times out on connections rather than returning the correct FCGI_OVERLOADED response. I did not understand dmitry's original reason for this: PHP cannot return FCGI_OVERLOADED, because all PHP processes are busy and nobody accepts new connection. Could you explain or perhaps review PHP's behaviour under overloaded conditions. Thanks Oliver [2007-12-17 10:44:55] oliver at realtsp dot com We have tried with http://snaps.php.net/php5.2-latest.tar.gz Result is unchanged. NOTE that the php workers and parent processes are still showing on ps after the crash (same as before the crash). But lightly cannot get a sensible response from them. [EMAIL PROTECTED] /usr/ports/lang/php5]# pstree ... |-+- 25262 www /usr/local/sbin/lighttpd -f /usr/local/etc/lighttpd.conf | \-+= 25263 www /usr/local/bin/php-cgi | |--- 25264 www /usr/local/bin/php-cgi | |--- 25265 www /usr/local/bin/php-cgi | |--- 25266 www /usr/local/bin/php-cgi | |--- 25267 www /usr/local/bin/php-cgi | |--- 25268 www /usr/local/bin/php
#43610 [Com]: fastcgi socket dies on high concurrency
ID: 43610 Comment by: olafvdspek at gmail dot com Reported By: oliver at realtsp dot com Status: Open Bug Type: CGI related Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Could you explain or perhaps review PHP's behaviour under overloaded conditions. I'm no PHP developer and haven't looked at the code, but my guess: A PHP process has C children, each being able to handle one connection. When that connection is closed, it'll do an accept() to handle a new connection. When a web server opens more than C connections, those will not be accepted until an existing connection is closed, which may take a long time. So a web server should never open more than C connections to one PHP process. Previous Comments: [2007-12-17 13:05:41] oliver at realtsp dot com Actually.. It turns out that the php parent is not dead at all. Even with stable 5.2.5 (rather than 5.2-latest) if you setup the fastcgi server to be started separately from lighty ie with lighty config like this: fastcgi.server = ( .php = ( localhost = ( socket = /tmp/php-fastcgi.sock ) ) ) and the use spawn_fcgi to start the php fcgi server manually. Then all behaves as expected. ie you get some (not all!!) 500s while the overload condition exists and when the load drops away you get all normal 200 responses again. ie elastic/tolerant performance as hoped for. After some investigation into the the lighty source it turns out that lighty is confused by the fact that PHP just fails to respond (ie timeout) rather than returning FCGI_OVERLOADED. refer to this: http://bugs.php.net/bug.php?id=39809 where dimitry said: PHP cannot return FCGI_OVERLOADED, because all PHP processes are busy and nobody accepts new connection. The only way to detect this situation - use connection timeout. lighty however is sticking to the fastcgi spec and expecting the php parent to be in shutdown mode (ie its PID to dissappear) when it does not respond (after which it would then respawn a new parent). But because the PHP parent is just busy and not actually shutting down, the PID never dissappears and lighty gets stuck in a loop. I have posted a workaround involving starting PHP separately here: http://trac.lighttpd.net/trac/ticket/1488 which also proposes a patch to deal with PHP's non-standard behaviour regarding FCGI_OVERLOADED. However, the fundamental problem remains: It is very difficult for a FASTCGI client to determine what is going on and therefore what to do when php just times out on connections rather than returning the correct FCGI_OVERLOADED response. I did not understand dmitry's original reason for this: PHP cannot return FCGI_OVERLOADED, because all PHP processes are busy and nobody accepts new connection. Could you explain or perhaps review PHP's behaviour under overloaded conditions. Thanks Oliver [2007-12-17 10:44:55] oliver at realtsp dot com We have tried with http://snaps.php.net/php5.2-latest.tar.gz Result is unchanged. NOTE that the php workers and parent processes are still showing on ps after the crash (same as before the crash). But lightly cannot get a sensible response from them. [EMAIL PROTECTED] /usr/ports/lang/php5]# pstree ... |-+- 25262 www /usr/local/sbin/lighttpd -f /usr/local/etc/lighttpd.conf | \-+= 25263 www /usr/local/bin/php-cgi | |--- 25264 www /usr/local/bin/php-cgi | |--- 25265 www /usr/local/bin/php-cgi | |--- 25266 www /usr/local/bin/php-cgi | |--- 25267 www /usr/local/bin/php-cgi | |--- 25268 www /usr/local/bin/php-cgi | |--- 25269 www /usr/local/bin/php-cgi | |--- 25270 www /usr/local/bin/php-cgi | |--- 25271 www /usr/local/bin/php-cgi | |--- 25272 www /usr/local/bin/php-cgi | |--- 25273 www /usr/local/bin/php-cgi | |--- 25274 www /usr/local/bin/php-cgi | |--- 25275 www /usr/local/bin/php-cgi | |--- 25276 www /usr/local/bin/php-cgi | |--- 25277 www /usr/local/bin/php-cgi | |--- 25278 www /usr/local/bin/php-cgi | \--- 25279 www /usr/local/bin/php-cgi [2007-12-17 09:17:30] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-12-16 21:55:00] oliver at realtsp dot com Description: Version information below. When I load the server with siege, once
#38915 [Com]: Apache: system() (and similar) don't cleanup opened handles of Apache
ID: 38915 Comment by: olafvdspek at gmail dot com Reported By: dimmoborgir at gmail dot com Status: Open Bug Type: Feature/Change Request Operating System: UNIX PHP Version: 5.2.2, 4.4.7 New Comment: Can't you use FastCGI and avoid issues like these completely? Previous Comments: [2007-10-07 09:33:33] Cruz at guerillamail dot com Ran into the same problem. I'm appalled that a bug this big isn't fixed more than a year after it was reported. [2007-07-29 10:48:18] antoine dot bajolet at tdf dot fr Hello, I agree with all contributors : It's a bunch of pain we can't launch a clean process from a PHP web interface. Without any technical consideration, functionally it's a real need to numerous PHP users, and for a long time seeing those bug reports : http://bugs.php.net/bug.php?id=15529 http://bugs.php.net/bug.php?id=15642 http://bugs.php.net/bug.php?id=16548 The only workaround whe found to obtain the result is : - Writing something to a file to tell hey, there is a process to launch or stop - Using a cron'ed script to read the file and launch/stop the process if it tells it. And this poor tip is far far from satisfying us. The last response given in 2003 was Given the nature of PHP's execution architecture this is not possible/practical to implement. But if the Apache API offers a apr_proc_create() function, why not using it in mod_php ? There are some other differences between mod_php and php-cli. Regards, Antoine [2007-03-05 21:11:51] oliver at realtsp dot com apart from the security considerations mentioned above the fact that mod_php doesn't free the FDs when forking prevents us from forking cleanly. ie we cannot from a web request to mod_php fork a cli process cleanly because it will inherit all the open FDs (ie typically port 80 443) even if you use setsid() (or daemon on FreeBSD) etc.. you can see this when you... fork stop apache netstat -an | grep LISTEN your cli process will be LISTENING to port 80 443. this is not only a security risk, but it will prevent apache for restarting: (48)Address already in use: make_sock: could not bind to address [::]:443 no listening sockets available, shutting down I have not found any way to close these sockets as they should be because the resource handles are not available in php. If you could at least make these available then we could at least ensure we close them manually. Regards Oliver [2007-01-04 19:25:26] anomie at users dot sf dot net On 20 Oct 2006 9:48am UTC, [EMAIL PROTECTED] wrote: The opened file descriptors are opened by Apache. It is the job of Apache to protect them, not something that should be reinvented in all apache modules. If that's your position, then as far as I can tell mod_php should be calling apr_proc_create() instead of system()/popen()/etc and apr_pool_cleanup_for_exec() before exec(). Apache adds (or should be adding) all the FDs that should be closed on exec to a list that those functions make use of. If you don't like that, then either explain (in as much detail as is required) why that isn't Apache's method of protecting the FDs, find a non-bogus reason for claiming this issue is not a mod_php bug, or just fix the bug already. Apache should just use FD_CLOEXEC isn't a non-bogus reason, BTW, although convincing Apache to do so and making sure FD_CLOEXEC is supported on all platforms mod_php can possibly be used on might be an acceptable bugfix. I've also seen the MTA ends up listening on port 80 issue after using the php mail functions. [2006-11-23 15:36:55] php at vanviegen dot net It seems that the mail() function is suffering from the same problem. It is rather scary to see Apache failing to restart, because the MTA (exim in our case) is already listening on port *:80 ! More details: http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20030407/msg00049.html 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/38915 -- Edit this bug report at http://bugs.php.net/?id=38915edit=1
#39954 [NEW]: ~ operator doesn't convert string to integer first
From: olafvdspek at gmail dot com
Operating system: Windows XP
PHP version: 5.2.0
PHP Bug Type: Scripting Engine problem
Bug description: ~ operator doesn't convert string to integer first
Description:
The ~ operator doesn't appear to convert a string to an integer first,
like most other operators do. This produces unexpected results of course.
Reproduce code:
---
$b = '0';
$b = ~$b;
printf('%s - %sbr', $b, ord($b));
$b = 0;
$b = ~$b;
printf('%s - %sbr', $b, ord($b));
Expected result:
-1 - 45
-1 - 45
Actual result:
--
Ï - 207
-1 - 45
--
Edit bug report at http://bugs.php.net/?id=39954edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39954r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39954r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39954r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39954r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39954r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39954r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39954r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39954r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39954r=support
Expected behavior:http://bugs.php.net/fix.php?id=39954r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39954r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39954r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39954r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39954r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39954r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39954r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39954r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39954r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39954r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39954r=mysqlcfg
#39954 [Bgs-Opn]: ~ operator doesn't convert string to integer first
ID: 39954
User updated by: olafvdspek at gmail dot com
Reported By: olafvdspek at gmail dot com
-Status: Bogus
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.2.0
New Comment:
What's the rationale behind that design?
And when is it useful?
Previous Comments:
[2006-12-26 15:58:42] [EMAIL PROTECTED]
Yes, it does not convert strings to numbers and this is by design. It
actualy runs the bitwise not operator on each character of the
string.
[2006-12-26 15:39:45] olafvdspek at gmail dot com
Description:
The ~ operator doesn't appear to convert a string to an integer first,
like most other operators do. This produces unexpected results of
course.
Reproduce code:
---
$b = '0';
$b = ~$b;
printf('%s - %sbr', $b, ord($b));
$b = 0;
$b = ~$b;
printf('%s - %sbr', $b, ord($b));
Expected result:
-1 - 45
-1 - 45
Actual result:
--
Ï - 207
-1 - 45
--
Edit this bug report at http://bugs.php.net/?id=39954edit=1
#39359 [Bgs-Opn]: Server API says 2.0 instead of 2.0
ID: 39359 User updated by: OlafvdSpek at Gmail dot Com Reported By: OlafvdSpek at Gmail dot Com -Status: Bogus +Status: Open Bug Type: Apache2 related Operating System: Windows XP PHP Version: 5.2.0 New Comment: It is the same sapi, 2.0 refers to major Apache version. But 2.0 is major.minor, shouldn't it say Apache 2 then? Previous Comments: [2006-11-03 19:57:46] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The sapi name does not change with the Apache version. It is the same sapi, 2.0 refers to major Apache version. [2006-11-03 13:17:59] OlafvdSpek at Gmail dot Com Description: Hi, phpinfo() says Server API: Apache 2.0 Handler although it's running on 2.2.3. Reproduce code: --- phpinfo(); Expected result: Server API: Apache 2.2 Handler Actual result: -- Server API: Apache 2.0 Handler -- Edit this bug report at http://bugs.php.net/?id=39359edit=1
#39359 [NEW]: Server API says 2.0 instead of 2.0
From: OlafvdSpek at Gmail dot Com Operating system: Windows XP PHP version: 5.2.0 PHP Bug Type: Apache2 related Bug description: Server API says 2.0 instead of 2.0 Description: Hi, phpinfo() says Server API: Apache 2.0 Handler although it's running on 2.2.3. Reproduce code: --- phpinfo(); Expected result: Server API: Apache 2.2 Handler Actual result: -- Server API: Apache 2.0 Handler -- Edit bug report at http://bugs.php.net/?id=39359edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39359r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39359r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39359r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39359r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39359r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39359r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39359r=needscript Try newer version:http://bugs.php.net/fix.php?id=39359r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39359r=support Expected behavior:http://bugs.php.net/fix.php?id=39359r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39359r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39359r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39359r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39359r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39359r=dst IIS Stability:http://bugs.php.net/fix.php?id=39359r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39359r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39359r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39359r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39359r=mysqlcfg
#32997 [NEW]: Warning for seeking to row 0
From: olafvdspek at gmail dot com
Operating system: Windows 2003
PHP version: 5.0.4
PHP Bug Type: MySQL related
Bug description: Warning for seeking to row 0
Description:
Hi,
PHP emits a bogus warning when you seek to row 0 in an empty result set.
Seeking to row 0 is a no-op in an empty set, but should not emit a
warning.
Reproduce code:
---
?php
mysql_connect('localhost', 'xbt', '');
mysql_select_db('xbt');
$rows = mysql_query(select 1 from xbt_files where 0 = 1) or
die(mysql_error());
mysql_data_seek($rows, 0);
?
Expected result:
No warning
Actual result:
--
Warning: mysql_data_seek() [function.mysql-data-seek]: Offset 0 is invalid
for MySQL result index 3 (or the query data is unbuffered) in
C:\IS\Apache2\htdocs\temp\data_seek.php on line 5
--
Edit bug report at http://bugs.php.net/?id=32997edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32997r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32997r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32997r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32997r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32997r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32997r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32997r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32997r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32997r=support
Expected behavior: http://bugs.php.net/fix.php?id=32997r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32997r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32997r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32997r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32997r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32997r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32997r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32997r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32997r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32997r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32997r=mysqlcfg
#32997 [Opn]: Warning for seeking to row 0
ID: 32997
User updated by: olafvdspek at gmail dot com
Reported By: olafvdspek at gmail dot com
Status: Open
Bug Type: MySQL related
Operating System: Windows 2003
PHP Version: 5.0.4
New Comment:
I see the documentation mentions this issue:
row_number starts at 0. The row_number should be a value in the range
from 0 to mysql_num_rows() - 1. However if the result set is empty
(mysql_num_rows() == 0), a seek to 0 will fail with a E_WARNING and
mysql_data_seek() will return FALSE.
Why does the seek not work like a normal fseek where you can also seek
to the end of the file (after you've read the last byte)?
Previous Comments:
[2005-05-10 11:32:20] olafvdspek at gmail dot com
Description:
Hi,
PHP emits a bogus warning when you seek to row 0 in an empty result
set. Seeking to row 0 is a no-op in an empty set, but should not emit a
warning.
Reproduce code:
---
?php
mysql_connect('localhost', 'xbt', '');
mysql_select_db('xbt');
$rows = mysql_query(select 1 from xbt_files where 0 = 1) or
die(mysql_error());
mysql_data_seek($rows, 0);
?
Expected result:
No warning
Actual result:
--
Warning: mysql_data_seek() [function.mysql-data-seek]: Offset 0 is
invalid for MySQL result index 3 (or the query data is unbuffered) in
C:\IS\Apache2\htdocs\temp\data_seek.php on line 5
--
Edit this bug report at http://bugs.php.net/?id=32997edit=1
