Req #54032 [Com]: ability to to handle Class not found error
Edit report at http://bugs.php.net/bug.php?id=54032&edit=1 ID: 54032 Comment by: tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:ability to to handle Class not found error Status: Open Type: Feature/Change Request Package:SPL related PHP Version:5.3.5 Block user comment: N Private report: N New Comment: after some sleep and a little bit thinking, I think that the best solution would be to introduce a new Exception type, which will be thrown if the execution of the autoload callbacks doesn't successfully load the class. what do you think? Tyrael Previous Comments: [2011-02-17 00:15:36] tyra3l at gmail dot com *exists -> exit *exection -> execution * spl autoload callbacks was executed -> spl autoload callbacks was executed without finding the class * I cannot continue the normal execution flow -> I couldn't continue the normal execution flow * from a higher level -> at a higher level sorry, its getting late, and my english skill degrades with sleep deprivation [2011-02-17 00:11:01] tyra3l at gmail dot com Description: currently you can throw an exception from the autoloader, hence if you can't find a class, your application can gracefully exists, instead of exiting via the class not found fatal error. my problem is, that I would like to use multiple autoloader (for example in a project which uses multiple component, or framework), but in this case, I can't throw an Exception from my autoloader, because maybe the other autoloaders could load the class. if I'm sure that I will register the last autoloader, the this isn't a problem(my last autoloader will throw the Exception on missing class), but maybe I have to load a component late of the exection. it would be cool, if I could somehow register a callback which will be called, when the spl autoload callbacks was executed, but the class couldn't be loaded of course, from this callback, I cannot continue the normal execution flow, however I can log the error, and let the callback return and get the class not found fatal error, or throw an Exception, and handle/log the error from a higher level. -- Edit this bug report at http://bugs.php.net/bug.php?id=54032&edit=1
Bug #54388 [Opn->Fbk]: Php segfaults when ob_end_clean() is called into ob handler
Edit report at http://bugs.php.net/bug.php?id=54388&edit=1
ID: 54388
Updated by: ahar...@php.net
Reported by:superbaloo at superbaloo dot net
Summary:Php segfaults when ob_end_clean() is called into ob
handler
-Status: Open
+Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Linux (at least)
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
I can't reproduce this on any machine I have to hand, so a backtrace is
definitely going to be needed here.
Previous Comments:
[2011-03-26 10:40:35] superbaloo at superbaloo dot net
Description:
This is an incorrect use of output buffering stuff okay ... but i don't
think
segfaults are a feature.
Test script:
---
function handler($message) {
ob_end_clean();
echo $message;
}
ob_start('handler');
echo "foo";
Expected result:
foo
Actual result:
--
segfault
--
Edit this bug report at http://bugs.php.net/bug.php?id=54388&edit=1
Bug #54403 [Opn->Bgs]: FILTER_VALIDATE_EMAIL
Edit report at http://bugs.php.net/bug.php?id=54403&edit=1 ID: 54403 Updated by: ahar...@php.net Reported by:mariomaresca at hotmail dot it Summary:FILTER_VALIDATE_EMAIL -Status: Open +Status: Bogus Type: Bug Package:Filter related Operating System: windows 7 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: That's a valid e-mail address: RFC 2822 only requires the local part to be a valid dot-atom, and dot-atom elements may end with a period. Previous Comments: [2011-03-27 19:29:56] mariomaresca at hotmail dot it Description: --- >From manual page: http://www.php.net/function.filter-var#Description --- filter_var with FILTER_VALIDATE_EMAIL takes as good this malformed email: "ma...@mail.com" Test script: --- $email='ma...@mail.com'; if (filter_var($email, FILTER_VALIDATE_EMAIL)) echo '$email is good'; else echo '$email is bad'; Expected result: $email is bad Actual result: -- $email is good -- Edit this bug report at http://bugs.php.net/bug.php?id=54403&edit=1
Bug #54411 [Opn->Bgs]: PHP Unit fails with comment tags in strings
Edit report at http://bugs.php.net/bug.php?id=54411&edit=1
ID: 54411
Updated by: ahar...@php.net
Reported by:ninja9578 at yahoo dot com
Summary:PHP Unit fails with comment tags in strings
-Status: Open
+Status: Bogus
Type: Bug
Package:Unknown/Other Function
Operating System: Ubuntu x86
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
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.
My guess is that you have an unclosed string somewhere earlier in your
script.
Previous Comments:
[2011-03-28 18:24:53] ninja9578 at yahoo dot com
Description:
If you have a string that contains the characters /* in PHPUnit, all the
tests
after it will be ignored because for some reason it thinks that it is a
comment.
A quick workaround is to add a block comment immediately after it.
public function testOne(){
//make sure that the directory is currently empty
foreach(glob('/tmp/ftp/*') as $fn) {
unlink($fn);
}
/* */ //<- this line is a workaround
}
Test script:
---
public function testOne(){
//make sure that the directory is currently empty
foreach(glob('/tmp/ftp/*') as $fn) {
unlink($fn);
}
}
public function testTwo(){
//This test case will not show up in the test list
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=54411&edit=1
Req #54152 [Asn->Csd]: Make FPM compatible with Apache HTTP Server 2.3 mod_proxy_fcgi
Edit report at http://bugs.php.net/bug.php?id=54152&edit=1 ID: 54152 User updated by:mark at catseye dot org Reported by:mark at catseye dot org Summary:Make FPM compatible with Apache HTTP Server 2.3 mod_proxy_fcgi -Status: Assigned +Status: Closed Type: Feature/Change Request Package:FPM related Operating System: Linux PHP Version:5.3SVN-2011-03-03 (snap) Assigned To:jimjag Block user comment: N Private report: N New Comment: v3 of the patch was applied to trunk in r309054 http://svn.php.net/viewvc?view=revision&revision=309054 Previous Comments: [2011-03-09 19:53:24] jim...@php.net Automatic comment from SVN on behalf of jimjag Revision: http://svn.php.net/viewvc/?view=revision&revision=309054 Log: Close [PHP-BUG] Req #54152... Apache 2.3.12 (and later) will now work correctly with PHP's fcgi impl with this patch. [2011-03-09 19:27:31] jim...@php.net Automatic comment from SVN on behalf of jimjag Revision: http://svn.php.net/viewvc/?view=revision&revision=309053 Log: Close [PHP-BUG] Req #54152... Apache 2.3.12 (and later) will now work correctly with PHP's fcgi impl with this patch. [2011-03-09 18:56:17] mark at catseye dot org Tested v3 of the patch against development snapshot php5.3-201103091530. Verified that the script gets executed, SCRIPT_FILENAME is set correctly, PATH_INFO is set correctly, and the php-fpm status page works. Compared output of phpinfo() between version 2 and version 3 of the patch for requests with extra-path components and query strings; did not find any discrepancies. Reviewed the patch itself and it looks good. [2011-03-07 19:50:54] jim...@php.net please try v3 of the patch... This limits the later on version of the changes to just be in effect when we know we're handling the proxy:fcgi:// stuff [2011-03-07 19:49:55] jim...@php.net The following patch has been added/updated: Patch Name: mod_proxy_fcgi-support-v3.patch Revision: 1299523794 URL: http://bugs.php.net/patch-display.php?bug=54152&patch=mod_proxy_fcgi-support-v3.patch&revision=1299523794 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=54152 -- Edit this bug report at http://bugs.php.net/bug.php?id=54152&edit=1
Bug #54403 [Com]: FILTER_VALIDATE_EMAIL
Edit report at http://bugs.php.net/bug.php?id=54403&edit=1
ID: 54403
Comment by: tomas dot brastavicius at quantum dot lt
Reported by:mariomaresca at hotmail dot it
Summary:FILTER_VALIDATE_EMAIL
Status: Bogus
Type: Bug
Package:Filter related
Operating System: windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
It is not correct. Address contains no characters other than atext
characters or "." surrounded by atext.
dot-atom = [CFWS] dot-atom-text [CFWS]
dot-atom-text = 1*atext *("." 1*atext)
Reference, http://tools.ietf.org/html/rfc2822#section-3.2.4
Previous Comments:
[2011-03-29 11:41:10] ahar...@php.net
That's a valid e-mail address: RFC 2822 only requires the local part to
be a valid dot-atom, and dot-atom elements may end with a period.
[2011-03-27 19:29:56] mariomaresca at hotmail dot it
Description:
---
>From manual page: http://www.php.net/function.filter-var#Description
---
filter_var with FILTER_VALIDATE_EMAIL takes as good this malformed
email:
"ma...@mail.com"
Test script:
---
$email='ma...@mail.com';
if (filter_var($email, FILTER_VALIDATE_EMAIL))
echo '$email is good';
else
echo '$email is bad';
Expected result:
$email is bad
Actual result:
--
$email is good
--
Edit this bug report at http://bugs.php.net/bug.php?id=54403&edit=1
Bug #54403 [Bgs]: FILTER_VALIDATE_EMAIL
Edit report at http://bugs.php.net/bug.php?id=54403&edit=1
ID: 54403
Updated by: dtajchre...@php.net
Reported by:mariomaresca at hotmail dot it
Summary:FILTER_VALIDATE_EMAIL
Status: Bogus
Type: Bug
Package:Filter related
Operating System: windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Once the expected/correct behavior is agreed upon, we should also add a
test case
for this. filter's behavior has been inconsistent across the last 10+
releases.
Previous Comments:
[2011-03-29 15:18:29] tomas dot brastavicius at quantum dot lt
It is not correct. Address contains no characters other than atext
characters or "." surrounded by atext.
dot-atom = [CFWS] dot-atom-text [CFWS]
dot-atom-text = 1*atext *("." 1*atext)
Reference, http://tools.ietf.org/html/rfc2822#section-3.2.4
[2011-03-29 11:41:10] ahar...@php.net
That's a valid e-mail address: RFC 2822 only requires the local part to
be a valid dot-atom, and dot-atom elements may end with a period.
[2011-03-27 19:29:56] mariomaresca at hotmail dot it
Description:
---
>From manual page: http://www.php.net/function.filter-var#Description
---
filter_var with FILTER_VALIDATE_EMAIL takes as good this malformed
email:
"ma...@mail.com"
Test script:
---
$email='ma...@mail.com';
if (filter_var($email, FILTER_VALIDATE_EMAIL))
echo '$email is good';
else
echo '$email is bad';
Expected result:
$email is bad
Actual result:
--
$email is good
--
Edit this bug report at http://bugs.php.net/bug.php?id=54403&edit=1
[PHP-BUG] Req #54417 [NEW]: Add string casting support for class/interface names
From:
Operating system: N/A
PHP version: Irrelevant
Package: Class/Object related
Bug Type: Feature/Change Request
Bug description:Add string casting support for class/interface names
Description:
Please add a way to get the fully qualified class or interface name without
the need to create an object. While it is possible to declare a static
variable in classes as a workaround, this will not work with interfaces, as
you can't declare members inside them. A common trick I've seen is to use a
constant:
namespace Foo\Bar;
interface A {
const __NAME = __CLASS__;
}
factory(Bar\A::__NAME); // calls factory with '\Foo\Bar\A'
Though this won't work with inheritance. The magic __NAMESPACE__ constant
is also no help when importing namespaces. I propose to use the __CLASS__
keyword to implement such a feature, as it is not allowed to have a class
constant of this name:
namespace Foo\Bar {
interface A {}
}
namespace Orange\Banana {
use Foo\Bar;
echo Bar\A::__CLASS__; // should print "Foo\Bar\A"
}
--
Edit bug report at http://bugs.php.net/bug.php?id=54417&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54417&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54417&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54417&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54417&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54417&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54417&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54417&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54417&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54417&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54417&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54417&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54417&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54417&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54417&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54417&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54417&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54417&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54417&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54417&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54417&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54417&r=mysqlcfg
[PHP-BUG] Bug #54418 [NEW]: http_build_query not accepting enc_type
From: Operating system: CentOS 5 PHP version: 5.3.6 Package: *General Issues Bug Type: Bug Bug description:http_build_query not accepting enc_type Description: According to the latest documentation, http_build_query should accept a fourth argument so you can specify the alternate RFC for encoding of spaces to %20 rather than + Checking the source however this does not appear to be the case, and this has not yet been implemented. Test script: --- Source: ZEND_BEGIN_ARG_INFO_EX(arginfo_http_build_query, 0, 0, 1) ZEND_ARG_INFO(0, formdata) ZEND_ARG_INFO(0, prefix) ZEND_ARG_INFO(0, arg_separator) ZEND_END_ARG_INFO() -- Edit bug report at http://bugs.php.net/bug.php?id=54418&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54418&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54418&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54418&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54418&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54418&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54418&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54418&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54418&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54418&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54418&r=support Expected behavior: http://bugs.php.net/fix.php?id=54418&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54418&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54418&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54418&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54418&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54418&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54418&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54418&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54418&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54418&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54418&r=mysqlcfg
Bug #52621 [Com]: pdo-oci fails to locate 64-bit Oracle installations
Edit report at http://bugs.php.net/bug.php?id=52621&edit=1 ID: 52621 Comment by: nfitzgerald at gmail dot com Reported by:jbnance at tresgeek dot net Summary:pdo-oci fails to locate 64-bit Oracle installations Status: Assigned Type: Bug Package:Oracle related Operating System: Linux PHP Version:5.3.3 Assigned To:sixd Block user comment: N Private report: N New Comment: Tested the patch for 5.3.3 and it works. Would be great to have this as part of the next release. Previous Comments: [2010-08-18 01:07:20] ka...@php.net Chris, now there is a patch for it, might be worth reviewing from an Oracle standpoint :) [2010-08-16 23:19:55] jbnance at tresgeek dot net Notes for end users, in order to use this you have to rebuild configure (buildconf --force after applying the patch). After applying and rebuilding, the following should work: ./configure --with-pdo-oci=instantclient,/usr,10.2.0.4 or ./configure --with-pdo-oci=shared,instantclient,/usr,10.2.0.4 Note that this is different from the non-PDO OCI configure option: --with-oci8=instantclient,/usr/lib/oracle/10.2.0.4/client64/lib or --with-oci8=shared,instantclient,/usr/lib/oracle/10.2.0.4/client64/lib (the version is a parameter in the PDO OCI option). [2010-08-16 23:18:54] jbnance at tresgeek dot net Added patches for 5.2 and 5.3 series. [2010-08-16 23:16:35] jbnance at tresgeek dot net Description: This is the same as bug 44989, but 44989 isn't getting any attention even though I have submitted a fix for the issue, and I'm not the original reporter so I can't update status. Test script: --- Using the Oracle provided 64bit InstantClient RPMs (currently using 11.1.0.1-1): ./configure --with-pdo-oci=instantclient,/usr/include,11.1.0 ... Produces: checking Oracle OCI support for PDO... yes checking Oracle Install-Dir... instantclient,/usr/include,11.1.0 checking if that is sane... yes checking for oci.h... configure: error: I'm too dumb to figure out where the include dir is in your Instant Client install Expected result: Libraries and headers located, compile succeeds. Actual result: -- Configure exits unable to locate libraries or headers. -- Edit this bug report at http://bugs.php.net/bug.php?id=52621&edit=1
Bug #52621 [Asn->Dup]: pdo-oci fails to locate 64-bit Oracle installations
Edit report at http://bugs.php.net/bug.php?id=52621&edit=1 ID: 52621 Updated by: s...@php.net Reported by:jbnance at tresgeek dot net Summary:pdo-oci fails to locate 64-bit Oracle installations -Status: Assigned +Status: Duplicate Type: Bug Package:Oracle related Operating System: Linux PHP Version:5.3.3 Assigned To:sixd Block user comment: N Private report: N New Comment: Duplicate of Bug #44989 Previous Comments: [2011-03-29 18:28:31] nfitzgerald at gmail dot com Tested the patch for 5.3.3 and it works. Would be great to have this as part of the next release. [2010-08-18 01:07:20] ka...@php.net Chris, now there is a patch for it, might be worth reviewing from an Oracle standpoint :) [2010-08-16 23:19:55] jbnance at tresgeek dot net Notes for end users, in order to use this you have to rebuild configure (buildconf --force after applying the patch). After applying and rebuilding, the following should work: ./configure --with-pdo-oci=instantclient,/usr,10.2.0.4 or ./configure --with-pdo-oci=shared,instantclient,/usr,10.2.0.4 Note that this is different from the non-PDO OCI configure option: --with-oci8=instantclient,/usr/lib/oracle/10.2.0.4/client64/lib or --with-oci8=shared,instantclient,/usr/lib/oracle/10.2.0.4/client64/lib (the version is a parameter in the PDO OCI option). [2010-08-16 23:18:54] jbnance at tresgeek dot net Added patches for 5.2 and 5.3 series. [2010-08-16 23:16:35] jbnance at tresgeek dot net Description: This is the same as bug 44989, but 44989 isn't getting any attention even though I have submitted a fix for the issue, and I'm not the original reporter so I can't update status. Test script: --- Using the Oracle provided 64bit InstantClient RPMs (currently using 11.1.0.1-1): ./configure --with-pdo-oci=instantclient,/usr/include,11.1.0 ... Produces: checking Oracle OCI support for PDO... yes checking Oracle Install-Dir... instantclient,/usr/include,11.1.0 checking if that is sane... yes checking for oci.h... configure: error: I'm too dumb to figure out where the include dir is in your Instant Client install Expected result: Libraries and headers located, compile succeeds. Actual result: -- Configure exits unable to locate libraries or headers. -- Edit this bug report at http://bugs.php.net/bug.php?id=52621&edit=1
Bug #44989 [Asn->Csd]: 64bit Oracle RPMs still not supported by pdo-oci
Edit report at http://bugs.php.net/bug.php?id=44989&edit=1 ID: 44989 Updated by: fel...@php.net Reported by:stevec at engr dot oregonstate dot edu Summary:64bit Oracle RPMs still not supported by pdo-oci -Status: Assigned +Status: Closed Type: Bug Package:PDO related Operating System: Linux PHP Version:5.2.6 Assigned To:sixd Block user comment: N Private report: N New Comment: 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/. Thank you for the report, and for helping us make PHP better. Thanks for the patch! Previous Comments: [2011-03-29 20:40:23] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=309818 Log: - Fixed bug #44989 (64bit Oracle RPMs still not supported by pdo-oci) patch by: jbnance at tresgeek dot net [2010-08-16 23:12:49] jbnance at tresgeek dot net Bug still exists in 5.3.3. Patch uploaded. [2010-08-04 01:03:29] jbnance at tresgeek dot net Patch attached for config.m4. Notes for end users, in order to use this you have to rebuild configure (buildconf --force after applying the patch). After applying and rebuilding, the following should work: ./configure --with-pdo-oci=instantclient,/usr,10.2.0.4 or ./configure --with-pdo-oci=shared,instantclient,/usr,10.2.0.4 Note that this is different from the non-PDO OCI configure option: --with-oci8=instantclient,/usr/lib/oracle/10.2.0.4/client64/lib or --with-oci8=shared,instantclient,/usr/lib/oracle/10.2.0.4/client64/lib (the version is a parameter in the PDO OCI option). [2009-05-03 01:00:13] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-04-27 15:55:23] stevec at eng dot orst dot edu I'm still seeing the same problem with the latest CVS snapshot (php5.2-200904271430). What it comes down to is the code is only looking for 'client' directories. The Oracle RPMs put everything in 'client64' directories. /usr/include/oracle/11.1.0.1/client64 /usr/lib/oracle/11.1.0.1/client64 As the previous poster mentioned, if you link the client directory in both of those directories to client64, then the compile works fine. That seems a bit of a kludge though. 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=44989 -- Edit this bug report at http://bugs.php.net/bug.php?id=44989&edit=1
[PHP-BUG] Bug #54419 [NEW]: is_dir() called on file with trailing slash to throw warning if open_basedir
From:
Operating system: Windows 7, Debian
PHP version: 5.3.6
Package: Safe Mode/open_basedir
Bug Type: Bug
Bug description:is_dir() called on file with trailing slash to throw warning if
open_basedir
Description:
is_dir throws an error if:
- open_basedir is in effect
- called upon a file
- the path is terminated with a slash
CLI Tested on Windows:
php -d open_basedir=/ -r "var_dump(is_dir('C:/Windows/write.exe'));"
#bool(false)
php -d open_basedir=/ -r "var_dump(is_dir('C:/Windows/write.exe/'));"
#warning
CLI Not tested on Linux, should be like this:
php -d open_basedir=/ -r "var_dump(is_dir('/etc/fstab'));"
Apache2 module tested on Debian, see test script.
Test script:
---
http://bugs.php.net/bug.php?id=54419&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54419&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54419&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54419&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54419&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54419&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54419&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54419&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54419&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54419&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54419&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54419&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54419&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54419&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54419&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54419&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54419&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54419&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54419&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54419&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54419&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54419&r=mysqlcfg
Req #54037 [Opn]: [PATCH] Adds the ability to pass options to loadHTML
Edit report at http://bugs.php.net/bug.php?id=54037&edit=1 ID: 54037 User updated by:fxmulder at gmail dot com Reported by:fxmulder at gmail dot com Summary:[PATCH] Adds the ability to pass options to loadHTML Status: Open Type: Feature/Change Request Package:DOM XML related PHP Version:trunk-SVN-2011-02-17 (SVN) Block user comment: N Private report: N New Comment: That works for me, this still good to be committed to the trunk? Previous Comments: [2011-03-03 08:12:00] chr...@php.net The following patch has been added/updated: Patch Name: patch-for-adding-loadhtml-options.patch Revision: 1299136320 URL: http://bugs.php.net/patch-display.php?bug=54037&patch=patch-for-adding-loadhtml-options.patch&revision=1299136320 [2011-03-03 08:11:04] chr...@php.net After talking with Rob, we removed LIBXML_RECOVER again. People don't like seeing that wildly used, there were and are always a lot of discussions, if that's a good thing at all. So we just remove the constant again for now. I'll attach the new patch. If noone complains, I will commit it soon [2011-02-22 17:11:08] chr...@php.net Looks fine to me, Will commit soon to trunk [2011-02-18 00:21:20] fxmulder at gmail dot com I've also included a patch to create new constants for use as options [2011-02-17 18:57:57] fxmulder at gmail dot com Description: This patch allows passing options directly to libxml for the loadHTML and loadHTMLFile DOMDocument functions -- Edit this bug report at http://bugs.php.net/bug.php?id=54037&edit=1
Bug #50175 [Com]: gmp_init() results 0 on given base and number starting with 0x or 0b
Edit report at http://bugs.php.net/bug.php?id=50175&edit=1
ID: 50175
Comment by: karl dot debisschop at pearson dot com
Reported by:thomas dot hebinck at digionline dot de
Summary:gmp_init() results 0 on given base and number
starting with 0x or 0b
Status: Open
Type: Bug
Package:GNU MP related
Operating System: Ubuntu
PHP Version:5.3.0
Block user comment: N
Private report: N
New Comment:
in php 5.3.6, the issue seems to be resolve with respect to "0x"
> php -r '$v = gmp_init("0x83", 36); print("$v\n");'
Resource id #4
> php -r '$v = gmp_init("0b83", 36); print("$v\n");'
> php -r '$v = gmp_init("0b83", 16); print("$v\n");'
Resource id #4
> php -r '$v = gmp_init("b83", 36); print("$v\n");'
Resource id #4
Also, the actual return value from gmp_init() is FALSE:
> php -r '$v = gmp_init("0b83", 36); if ($v === FALSE)
print("false\n");'
false
Previous Comments:
[2009-11-14 13:46:52] thomas dot hebinck at digionline dot de
Description:
When calling gmp_init() with a *string* starting with 0x or 0b and a
given base, 0 is returned (except if the base is 16).
Tested with PHP 5.2.3, PHP 5.3 and PHP 5.3-200911141130.
Reproduce code:
---
for($base=2;$base<=36;$base++) {
echo ''.$base.': ';
for($i=1;$i<$base;$i++) {
$c=($i<=9?$i:chr($i-10+ord('a')));
$s='0'.$c.$c;
echo gmp_strval(gmp_init($s,$base),$base) . ' ';
}
}
Expected result:
2: 11
3: 11 22
4: 11 22 33
5: 11 22 33 44
6: 11 22 33 44 55
7: 11 22 33 44 55 66
8: 11 22 33 44 55 66 77
9: 11 22 33 44 55 66 77 88
10: 11 22 33 44 55 66 77 88 99
11: 11 22 33 44 55 66 77 88 99 aa
12: 11 22 33 44 55 66 77 88 99 aa bb
13: 11 22 33 44 55 66 77 88 99 aa bb cc
14: 11 22 33 44 55 66 77 88 99 aa bb cc dd
15: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee
16: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
17: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg
18: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh
19: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii
20: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii jj
21: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii jj kk
22: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii jj kk ll
23: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii jj kk ll mm
24: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii jj kk ll mm nn
25: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii jj kk ll mm nn
oo
26: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii jj kk ll mm nn
oo pp
27: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii jj kk ll mm nn
oo pp qq
28: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii jj kk ll mm nn
oo pp qq rr
29: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii jj kk ll mm nn
oo pp qq rr ss
30: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii jj kk ll mm nn
oo pp qq rr ss tt
31: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii jj kk ll mm nn
oo pp qq rr ss tt uu
32: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii jj kk ll mm nn
oo pp qq rr ss tt uu vv
33: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii jj kk ll mm nn
oo pp qq rr ss tt uu vv ww
34: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii jj kk ll mm nn
oo pp qq rr ss tt uu vv ww xx
35: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii jj kk ll mm nn
oo pp qq rr ss tt uu vv ww xx yy
36: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff gg hh ii jj kk ll mm nn
oo pp qq rr ss tt uu vv ww xx yy zz
Actual result:
--
2: 11
3: 11 22
4: 11 22 33
5: 11 22 33 44
6: 11 22 33 44 55
7: 11 22 33 44 55 66
8: 11 22 33 44 55 66 77
9: 11 22 33 44 55 66 77 88
10: 11 22 33 44 55 66 77 88 99
11: 11 22 33 44 55 66 77 88 99 aa
12: 11 22 33 44 55 66 77 88 99 aa 0
13: 11 22 33 44 55 66 77 88 99 aa 0 cc
14: 11 22 33 44 55 66 77 88 99 aa 0 cc dd
15: 11 22 33 44 55 66 77 88 99 aa 0 cc dd ee
16: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
17: 11 22 33 44 55 66 77 88 99 aa 0 cc dd ee ff gg
18: 11 22 33 44 55 66 77 88 99 aa 0 cc dd ee ff gg hh
19: 11 22 33 44 55 66 77 88 99 aa 0 cc dd ee ff gg hh ii
20: 11 22 33 44 55 66 77 88 99 aa 0 cc dd ee ff gg hh ii jj
21: 11 22 33 44 55 66 77 88 99 aa 0 cc dd ee ff gg hh ii jj kk
22: 11 22 33 44 55 66 77 88 99 aa 0 cc dd ee ff gg hh ii jj kk ll
23: 11 22 33 44 55 66 77 88 99 aa 0 cc dd ee ff gg hh ii jj kk ll mm
24: 11 22 33 44 55 66 77 88 99 aa 0 cc dd ee ff gg hh ii jj kk ll mm nn
25: 11 22 33 44 55 66 77 88 99 aa 0 cc dd ee ff gg hh ii jj kk ll mm nn
oo
26: 11 22 33 44 55 66 77 88 99 aa 0 cc dd ee ff gg hh ii jj kk ll mm nn
oo pp
27: 11 22 33 44 55 66 77 88 99 aa 0 cc dd ee ff gg hh ii jj kk ll mm nn
oo pp qq
28: 11 22 33 44 55 66 77 88 99 aa 0 cc dd ee ff g
[PHP-BUG] Bug #54421 [NEW]: bindValue does not process utf-8 encoded strings.
From:
Operating system: Found on win and linux(centos)
PHP version: 5.3.6
Package: PDO related
Bug Type: Bug
Bug description:bindValue does not process utf-8 encoded strings.
Description:
I'm currently developing a piece of software system for a Russian client.
When set names is set as utf8 in both execute and as one of the options in
the PDO construct, no results are returned when a utf8 string is bound
using bindValue();
Test script:
---
$stmt = $pdo->prepare('SELECT * FROM table WHERE column LIKE ?');
$stmt->bindValue(1,\'%пÑивеÑ%\');
$stmt->execute();
$result = $stmt->fetchAll(PDO::FETCH_ASSOC);
var_dump($result);
Expected result:
array(1) { "column" => "пÑивеÑ" }
Actual result:
--
array(0){}
--
Edit bug report at http://bugs.php.net/bug.php?id=54421&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54421&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54421&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54421&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54421&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54421&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54421&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54421&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54421&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54421&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54421&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54421&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54421&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54421&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54421&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54421&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54421&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54421&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54421&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54421&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54421&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54421&r=mysqlcfg
