[PHP-BUG] Bug #60639 [NEW]: ReflectionFunction::IS_DEPRECATED is not used anywhere
From: vrana Operating system: Irrelevant PHP version: trunk-SVN-2012-01-03 (SVN) Package: Reflection related Bug Type: Bug Bug description:ReflectionFunction::IS_DEPRECATED is not used anywhere Description: The ReflectionFunction class defines a constant IS_DEPRECATED which is not used anywhere. There is a method ReflectionFunction::isDeprecated() but it doesn't use this constant. -- Edit bug report at https://bugs.php.net/bug.php?id=60639&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60639&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60639&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60639&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60639&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60639&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60639&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60639&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60639&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60639&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60639&r=support Expected behavior: https://bugs.php.net/fix.php?id=60639&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60639&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60639&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60639&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60639&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60639&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60639&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60639&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60639&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60639&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60639&r=mysqlcfg
Bug #60626 [Asn->Bgs]: filter_var crash
Edit report at https://bugs.php.net/bug.php?id=60626&edit=1
ID: 60626
Updated by: paj...@php.net
Reported by:stephanvanruth at gmail dot com
Summary:filter_var crash
-Status: Assigned
+Status: Bogus
Type: Bug
Package:*General Issues
Operating System: Win 7 x64
PHP Version:5.4.0RC4
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
See http://msdn.microsoft.com/en-us/library/xd3shwhf(v=vs.71).aspx
And no, no need to assign to me, there is no bug.
We do not control how apache is built nor how it is configured (stack size
option).
Cheers.
Previous Comments:
[2011-12-31 14:02:09] stephanvanruth at gmail dot com
t.php:
Success!
test.txt has been created and contains the given string.
works with both:
php t.php
php -n t.php
Thnx for this, whenever I 'think' I have found a bug, I will try this first.
I'm gonna google "Apache stack too small" now.
Happy New Year!
Stephan
[2011-12-31 11:14:15] paj...@php.net
It sounds to me like your stack is too small, are you using it within Apache?
Can you try in CLI using php.exe t.php and then using php.exe -n t.php please?
[2011-12-29 22:29:48] stephanvanruth at gmail dot com
Description:
Crash when a string longer than 225 characters (while containing @) is passed
to filter_var
Test script:
---
filter_var('the-total-len...@of-an-entire-address.cannot-be-longer-than-two-hundred-and-fifty-four-characters.and-this-address-is-254-characters-exactly.so-it-should-be-valid.and-im-going-to-add-some-more-words-here.to-increase-the-lenght-blah-blah-blah-blah-bla.org',
FILTER_VALIDATE_EMAIL);
Expected result:
return the input given
Actual result:
--
crash
--
Edit this bug report at https://bugs.php.net/bug.php?id=60626&edit=1
Bug #60077 [Com]: SoapServer ignores type hinting
Edit report at https://bugs.php.net/bug.php?id=60077&edit=1 ID: 60077 Comment by: encard at p5r dot ru Reported by:encard at p5r dot ru Summary:SoapServer ignores type hinting Status: Open Type: Bug Package:SOAP related Operating System: Ubuntu 11.04 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: It's equivalent to type of $a variable (line #33 of test script) which now is integer. Previous Comments: [2011-11-07 16:53:27] will dot fitch at gmail dot com What is the result of gettype($arr)? [2011-10-17 16:13:21] encard at p5r dot ru Description: Type hinting is totally ignored on every code executed by SoapServer object during SOAP request. Test script: --- http://textuploader.com/?p=6&id=T8LNv Expected result: Fatal error. Actual result: -- Type hinting is ignored. -- Edit this bug report at https://bugs.php.net/bug.php?id=60077&edit=1
Bug #55760 [Com]: Can not load php_ldap.dll
Edit report at https://bugs.php.net/bug.php?id=55760&edit=1 ID: 55760 Comment by: david at bridgehouse dot org dot za Reported by:mod4wb at heysoft dot de Summary:Can not load php_ldap.dll Status: Bogus Type: Bug Package:LDAP related Operating System: Windows PHP Version:5.3.8 Block user comment: N Private report: N New Comment: I have had the same problem using XAMPP 1.7.7 VC9 on Windows Server 2008 R2. First point to note is that you need the C++ redistributable (x86) to get anything to work on a Win64 system using Apache. The next thing is that if php_LDAP.dll will not load it could be because you do not have c:\xampp\php in you PATH environment variable. Properties of computer -> Advanced System Settings-> Advanced Tab->Environmental Variables..->System Variables ->Path->edit Add the path to you php folder. Now that was not too hard was it, guys? DavidR Previous Comments: [2011-10-20 15:50:06] mod4wb at heysoft dot de Adding any path does not help, because on a fresh Windows, you will not find the files. So you need to download them from the internet and all will work. The problem is that the developer does have additional software (VC) on his machine, which installed the required files, and therefore he can not reproduce the problem. Installing a fresh Windows and checking whether his software runs there is not what one can expect from a super star. Sure php would run without the problem files (it did until them have been included, and dependency walker shows that no function from this dlls is ever used) but for this one would need to agree that a suboptimal solution has been delivered. [2011-10-20 10:07:23] paj...@php.net no, see the windows documentation to know how to add it to your PATH, per user or system wide. [2011-10-20 09:48:02] ramki067 at gmail dot com Any update on the issue i faced? [2011-10-13 03:47:11] ramki067 at gmail dot com You have said in your earlier posts as, "Add the internet explorer directory to your path". Is this the solution to the problem? If yes, how where should the internet explorer path be added. Please advice. Thanks. [2011-10-12 10:53:51] paj...@php.net See my previous comment, not much we can do against that. Also to fix your setup is rather easy. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55760 -- Edit this bug report at https://bugs.php.net/bug.php?id=55760&edit=1
[PHP-BUG] Bug #60637 [NEW]: Lexer is full of memory leaks
From:
Operating system:
PHP version: trunk-SVN-2012-01-02 (SVN)
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Lexer is full of memory leaks
Description:
zend_language_scanner.l has quite a big number of leaks:
- require('non-existent-file') - 2 leaks
- include('file-with-parse-error')
- every usage of zend_copy_value must be audited -- on a parse error it's
likely the memory will be leaked.
(run with USE_ZEND_ALLOC=0)
--
Edit bug report at https://bugs.php.net/bug.php?id=60637&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60637&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60637&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60637&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60637&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60637&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60637&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60637&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60637&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60637&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60637&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60637&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60637&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60637&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60637&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60637&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60637&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60637&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60637&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60637&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60637&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60637&r=mysqlcfg
[PHP-BUG] Bug #60636 [NEW]: Dots in folders results in a open_basedir restriction warning
From: Operating system: Linux PHP version: 5.3.8 Package: Safe Mode/open_basedir Bug Type: Bug Bug description:Dots in folders results in a open_basedir restriction warning Description: If you try to access a file within a folder that has a dot, an open_basedir restriction warning will show up even if the folder is in the allowed paths list. Test script: --- function.file- exists]: open_basedir restriction in effect. File(/home/example/public_html/myfolder.example/file.php) is not within the allowed path(s): (/home/example:/usr/lib/php:/tmp) in /home/example/public_html/test.php on line 3 -- Edit bug report at https://bugs.php.net/bug.php?id=60636&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60636&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60636&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60636&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60636&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60636&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60636&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60636&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60636&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60636&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60636&r=support Expected behavior: https://bugs.php.net/fix.php?id=60636&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60636&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60636&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60636&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60636&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60636&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60636&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60636&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60636&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60636&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60636&r=mysqlcfg
Req #32100 [Com]: Request 'finally' support for exceptions
Edit report at https://bugs.php.net/bug.php?id=32100&edit=1
ID: 32100
Comment by: frederic dot hardy at mageekbox dot net
Reported by:ceefour at gauldong dot net
Summary:Request 'finally' support for exceptions
Status: Closed
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: *
PHP Version:5.*
Block user comment: N
Private report: N
New Comment:
I'm not sure that this place is the right place to discuss about that.
Since the last year, PHP has a process to discuss technical point, aka RFC
(https://wiki.php.net/rfc).
So, if "finally" must be included in PHP, just write the relative RFC and
discuss
it on internals.
Sure that time has changed, because PHP's users are more power now than in the
past !
Previous Comments:
[2011-12-08 17:40:44] antoninweb at gmail dot com
I don't understand how this is not included when PHP supports try...catch. It
just
doesn't makes sense and it's annoying because you have to find ways around it
contantly.
[2011-12-06 05:50:29] ben at last dot fm
"finally" would be a majorly beneficial addition to the language. It's
something
we yearn for here at last.fm.
[2011-12-05 17:55:43] php dot net at kenman dot net
+1
>From Zeev, in the 2000 discussion:
> try..finally doesn't make much sense in the context of PHP [...] Nobody has
> ever
asked for this in the past either.
Those days are long past, please take this bug report's comments as a sign that
this *does* now make sense for PHP.
[2011-12-05 15:53:28] topaz dot php dot bugs at lt3 dot us
Ugly workaround hack time!
(This is not a substitute for a real language feature!)
Mix and match with try/catch blocks as necessary.
invoke();
print "Example 1 ended normally.\n";
}
function example2()
{
$finally = new Finally("example_finally");
print "Throwing exception!\n";
throw new Exception("Something exceptional happened!");
$finally->invoke();
print "Example 2 ended normally.\n";
}
// Test harness
print "Example 1...\n";
try
{
example1();
}
catch (Exception $e)
{
print "Example 1 threw an exception!\n";
}
print "\nExample 2...\n";
try
{
example2();
}
catch (Exception $e)
{
print "Example 2 threw an exception!\n";
}
// Implementation of the Finally class
class Finally
{
private $_callback = NULL;
private $_args = array();
function __construct($callback, array $args = array())
{
if (!is_callable($callback))
{
throw new Exception("Callback was not callable!");
}
$this->_callback = $callback;
$this->_args = $args;
}
public function invoke()
{
if ($this->_callback)
{
call_user_func_array($this->_callback, $args);
$this->_callback = NULL;
$this->_args = array();
}
}
function __destruct()
{
$this->invoke();
}
}
[2011-11-18 00:25:23] chiestand at salk dot edu
First, thank you everyone who has contributed to this bug report thread. Your
insights have been incredibly useful.
I too vote for inclusion of "finally" into PHP. In my own particular situation
I was
able to solve my problem using Stroustrup's RAII pattern (thank you btsai). But
I can
imagine that in some cases creating a class for every resource used might be
inconvenient.
I think ceefour really summed it up nicely back in 2005 with even more-ancient
wisdom: "Be conservative with what you emit and be liberal with what you
accept".
Provide the tool, and let the coder decide what pattern to use.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=32100
--
Edit this bug report at https://bugs.php.net/bug.php?id=32100&edit=1
