#39946 [Com]: Native Singleton Implementation
ID: 39946
Comment by: toomuchphp-phpbugs at yahoo dot com
Reported By: scott dot mcnaught at synergy8 dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 6CVS-2006-12-25 (CVS)
New Comment:
Perhaps some nicer solutions to your got-cha's:
- What happens when $members = new members() is called
If the class is defined as a singleton, then PHP should create the
instance as
normal (this includes calling __construct() ) and store it in the hash
table,
or return the cached instance if it's already created.
-- I say an exception being thrown and a suggestion to remove new
You should still be able to use 'new', with the expectation that if the
class
is a singleton, you might actually get a cached instance, rather than a
'new'
instance, but it's not very difficult to understand:
$a = new members;
$b = new members;
$c = new members;
// $a $b and $c are all the same instance because members is a
singleton
If you really think 'new' is too ambiguous, why not add a new token
such as
'only', which is used for instantiation of singletons?
$a = only members;
$b = only members;
$c = only members;
// it's a bit more obvious $a $b and $c are the same instance.
- Is it ok to go $members = members; ?
That's too ambiguous. In that example 'members' could be a constant,
singleton, or simply the string 'members'.
- Singleton constructors should not have parameters
Perhaps they could (and it might be useful), if it's done like this:
singleton class members { ... }
$foo = new members(1, 2, 3); // arguments are passed to __construct()
$bar = new members(3, 2, 1); // arguments are ignored, object has
already been constructed
$baz = new members(4, 5, 6); // arguments are ignored, object has
already been constructed
- Perhaps a new function singleton_getobjects needs to be added to
enable access to the internal hash table
Not a bad idea. Getting in 'through the back door' is really important.
Why not
also a 'singleton_is_loaded()', and an 'is_singleton()'? Obviously
this would
eventually need to be visible through the Reflection classes (etc,
etc).
- Never have singleton abstract classes?
I think that would be an unfair limitation.
You should just need to:
- add T_SINGLETON to the parser.
- add an is_singleton flag for class definitions, activated by
T_SINGLETON.
- overload the 'new' operator to retrieve from the hash table if the
class is
a singleton (otherwise call __construct() as normal).
- implement some of those helper functions such as
singleton_getobjects().
Previous Comments:
[2006-12-29 08:23:57] scott dot mcnaught at synergy8 dot com
But the term singleton and static class are two different things.
The problem with pure static classes is that you can't inherit because
an instance is never created.
With static classes, you arent invoking methods on an instance of a
class. You are simply calling static functions in a static namespace.
[2006-12-29 07:59:22] me at bashkim dot com dot au
I think the term singleton itself is a little confusing for newbies
(considering that it's who you want to target here). Perhaps what
you're looking for is a static class ...
?php
static class Members
{
...
}
?
[2006-12-25 17:45:13] scott dot mcnaught at synergy8 dot com
Description:
###
# Introduction
###
This document is an RFC for adding a small patch to the zend engine to
allow for native singleton classes. The problem
is that currently theres no clean way to implement singleton classes in
user-land over the entirety of a project.
Singleton classes are beneficial because:
- Removes the overhead of having multiple instances of the one object
when there is no need
- Allows you to keep the objects state rather than always starting from
an initial state.
- They provide namespaces with the benefits of polymorphism (eg -
singleton classes can override / inherit from each other)
Throughout this document, I will use an example of a singleton class
members which acts as an interface to a database table.
This class can save and load members from this database table simply by
calling the following methods in this class.
members::get($member_id) Loads a member from a member id and returns an
associative array with info about that member
members::save($member) Saves a member to the database from an array of
properties about that member
With the recent phase of tiered and service oriented architecture, the
need for Singleton has become more and more apparent.
###
# Singleton in php5
###
In the past, I have implemented Singleton two different ways. Both of
these have problems.
# Method 1:
The first method involves having a public
#39835 [Com]: Configure script fails with expr: syntax error
ID: 39835 Comment by: toomuchphp-phpbugs at yahoo dot com Reported By: cheetah at tanabi dot org Status: Open Bug Type: *Compile Issues Operating System: Solaris 10 PHP Version: 5.2.0 New Comment: I had the some problem on OS X upgrading to 5.2, you just need to upgrade your shell (e.g., bash). Previous Comments: [2006-12-14 22:05:55] cheetah at tanabi dot org Description: Two notes; I have tried this on two separate Solaris 10 machines and I get this exact same error on both. On both machines, past versions of PHP have successfully compiled -- namely PHP 5.1.6 and a few earlier ones as well. Not doing anything particularly special here other than a 64 bit build (we use a large memory application with this) WHICH worked perfectly fine with 5.1.6... The flags to build 64 bit are in CFLAGS and LDFLAGS, namely -mcpu=ultrasparc -m64 here's what happens: ./configure --prefix=/usr/local/64 --enable-sysvmsg --enable-sysvsem --enable-sysvshm --enable-sockets --with-pgsql=/usr/local/64/pgsql --with-pdo-pgsql=/usr/local/64/pgsql --with-libxml-dir=/usr/local/64 --enable-ftp --without-iconv loading cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for egrep... egrep checking for a sed that does not truncate output... /usr/local/bin/sed expr: syntax error ./configure: test: argument expected 'expr' shows up only about 60 billion times in the file, and I have been unable to reasonably isolate which one is actually failing. Too bad shell scripts aren't nice enough to provide a line number! :) I'm hoping someone can help me out here, and appologies if this has already been reported -- I did search the bug DB for quite awhile before posting :) Thanks! Reproduce code: --- N/A Expected result: N/A Actual result: -- N/A -- Edit this bug report at http://bugs.php.net/?id=39835edit=1
#39775 [NEW]: Indirect modification ... message is not shown
From: toomuchphp-phpbugs at yahoo dot com
Operating system: OS X
PHP version: 5.2.0
PHP Bug Type: Class/Object related
Bug description: Indirect modification ... message is not shown
Description:
If a __get() method returns a variable which is a reference, the 'Indirect
modification of ...' error will not be shown.
Reproduce code:
---
class test {
var $array = array();
function __get($var) {
$v = $this-array;
return $this-array;
}
}
$t = new test;
$t-anything[] = 'bar';
print_r($t-anything);
Expected result:
Notice: Indirect modification of overloaded property test::$anything has
no effect in test.php on line 10
Array
(
)
Actual result:
--
Array
(
)
--
Edit bug report at http://bugs.php.net/?id=39775edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39775r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39775r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39775r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39775r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39775r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39775r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39775r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39775r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39775r=support
Expected behavior:http://bugs.php.net/fix.php?id=39775r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39775r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39775r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39775r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39775r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39775r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39775r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39775r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39775r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39775r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39775r=mysqlcfg
#39689 [NEW]: PHP converts float to integer incorrectly
From: toomuchphp-phpbugs at yahoo dot com Operating system: Mac OS X PHP version: 5.2.0 PHP Bug Type: Math related Bug description: PHP converts float to integer incorrectly Description: PHP converts some floats to integers incorrectly (I only know of one example). Reproduce code: --- ?php echo strval(2169.99 * 100), \n; echo intval(2169.99 * 100), \n; // converts incorrectly Expected result: 216999 216999 Actual result: -- 216999 216998 -- Edit bug report at http://bugs.php.net/?id=39689edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39689r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39689r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39689r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39689r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39689r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39689r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39689r=needscript Try newer version:http://bugs.php.net/fix.php?id=39689r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39689r=support Expected behavior:http://bugs.php.net/fix.php?id=39689r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39689r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39689r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39689r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39689r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39689r=dst IIS Stability:http://bugs.php.net/fix.php?id=39689r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39689r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39689r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39689r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39689r=mysqlcfg
#38122 [Opn]: Misleading error message for recursive use of __get()
ID: 38122
User updated by: toomuchphp-phpbugs at yahoo dot com
Reported By: toomuchphp-phpbugs at yahoo dot com
Status: Open
-Bug Type:Feature/Change Request
+Bug Type:Class/Object related
-PHP Version: 5.1.4
+PHP Version: 5.2.0RC1
New Comment:
Also occurs in PHP-5.2.0RC1.
Previous Comments:
[2006-07-17 08:14:27] toomuchphp-phpbugs at yahoo dot com
Description:
Recursive use of __get() results in the misleading error message
Notice: Undefined property: someClass::$foo in file.php. It appears
at first as though __get() is not being called for some properties and
there is no apparent reason why, when the problem is really accidental
recursion. PHP correctly detects the recursion and aborts __get(), but
the error gives no indication of the recursion problem and it can be
very difficult to figure out why __get() is not being called.
I can provide a fix for zend_object_handlers.c, but it really is just a
60-second change to capture the recursiveness error and output an
alternative error message.
Reproduce code:
---
class test {
function __get($var) {
return $this-$var;
}
}
$obj = new test;
echo $obj-foo;
Expected result:
Warning: Recursive use of __get() while accessing test::$foo; cannot
read property recursive::$foo in file on line x
Actual result:
--
Notice: Undefined property: test::$foo in file on line x
--
Edit this bug report at http://bugs.php.net/?id=38122edit=1
#38122 [NEW]: Misleading error message for recursive use of __get()
From: toomuchphp-phpbugs at yahoo dot com
Operating system:
PHP version: 5.1.4
PHP Bug Type: Class/Object related
Bug description: Misleading error message for recursive use of __get()
Description:
Recursive use of __get() results in the misleading error message Notice:
Undefined property: someClass::$foo in file.php. It appears at first as
though __get() is not being called for some properties and there is no
apparent reason why, when the problem is really accidental recursion. PHP
correctly detects the recursion and aborts __get(), but the error gives no
indication of the recursion problem and it can be very difficult to figure
out why __get() is not being called.
I can provide a fix for zend_object_handlers.c, but it really is just a
60-second change to capture the recursiveness error and output an
alternative error message.
Reproduce code:
---
class test {
function __get($var) {
return $this-$var;
}
}
$obj = new test;
echo $obj-foo;
Expected result:
Warning: Recursive use of __get() while accessing test::$foo; cannot read
property recursive::$foo in file on line x
Actual result:
--
Notice: Undefined property: test::$foo in file on line x
--
Edit bug report at http://bugs.php.net/?id=38122edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38122r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38122r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38122r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38122r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38122r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38122r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38122r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38122r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38122r=support
Expected behavior:http://bugs.php.net/fix.php?id=38122r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38122r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38122r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38122r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38122r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38122r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38122r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38122r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38122r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38122r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38122r=mysqlcfg
#34804 [Opn]: More information about static class methods
ID: 34804
User updated by: toomuchphp-phpbugs at yahoo dot com
-Summary: More information about stclass methods
Reported By: toomuchphp-phpbugs at yahoo dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Any
PHP Version: 5.x
New Comment:
The reason why some of the bug reports get dismissed so easily is
because they ask for one of the existing features ('self' or
'__CLASS__') to be modified to solve this problem, but 'self' and
'__CLASS__' are both already very useful and proably very widely used,
so it's not good to change them, and therefore we need a *new way* to
find out what class the static method was part of.
Something I find very disappointing is the fact that bug #30828
destroyed the only existing solution to this problem -
debug_backtrace(). In PHP 5.0.4, debug_backtrace() could have been
used here to discover the static class name, but somebody wanted it
working the other way (like __CLASS__ instead), the bug was reported,
fixed in 5.0.5, and so we lost our only solution to this problem. This
bugfix actually broke some of my existing code a year ago when it was
released, but it wasn't so important to me at the time. It's only over
the past year as I've been writing object-oriented code full time, and
studying implementations by other languages (Java, AspectJ, Ruby) that
I've realized how damaging the change to debug_backtrace() was.
I am hoping that as Zend continue writing their Framework, they'll
realize just how broken static methods are and will try to fix them
somehow.
Previous Comments:
[2006-06-19 20:41:34] DouglasStewart at creighton dot edu
I am unsure where to comment on this. This particular issue that folks
are having with __CLASS__ and self not playing in the proper calling
context makes life very difficult. The bug report responses like This
is not a bug and is designed and intended to work that way are, I
suppose, the discretion of the current developer base or ZEND or
whoever.
Maybe if someone could elaborate on the wisdom of this design decision.
Imparting this knowledge may illuminate the reasons why this feature
that many OO programmers are accustomed to having available is being
dismissed so readily.
The current implementation of __CLASS__ is not useful.
If you wish to ask a class for its name, php is not yet prepared to
provide you with the answer. The following examples illustrate why:
class TopClass {
public static function ClassNameIndirect() {
return self::ClassName();
}
public static function ClassName() {
return 'TopClass';
}
public static function ClassNameKeyword() {
return __CLASS__;
}
public static function ClassNameKeywordUninherited() {
return self::ClassNameKeyword();
}
public static function ClassNameSelfInstance() {
$object = new self;
return get_class($object);
}
public static function ClassNameSelfInstanceUninherited() {
return self::ClassNameSelfInstance();
}
public static function ClassNameKeywordUninheritedIndirect() {
return self::ClassNameKeywordUninherited();
}
public static function ClassNameSelfInstanceUninheritedIndirect() {
return self::ClassNameSelfInstanceUninherited();
}
public static function ClassNameHack() {
$bt = debug_backtrace();
$name = $bt[0]['class'];
return $name;
}
public static function ClassNameHackUninherited() {
return self::ClassNameHack();
}
}
class BottomClass extends TopClass {
public static function ClassName() {
return 'BottomClass';
}
public static function ClassNameKeywordUninherited() {
return __CLASS__;
}
public static function ClassNameSelfInstanceUninherited() {
$object = new self;
return get_class($object);
}
public static function ClassNameHackUninherited() {
$bt = debug_backtrace();
$name = $bt[0]['class'];
return $name;
}
}
echo 'br /(1)*** Results for a static and constant class name
implementation ***';
echo 'br /ClassName() for TopClass: ' .
TopClass::ClassNameIndirect();
echo 'br /ClassName() for BottomClass: ' .
BottomClass::ClassNameIndirect();
echo 'br /';
echo 'br /(2)*** Results for an inherited __CLASS__ implementation
***';
echo 'br /ClassName() for TopClass: ' .
TopClass::ClassNameKeyword();
echo 'br /ClassName() for BottomClass: ' .
BottomClass::ClassNameKeyword();
echo 'br /';
echo 'br /(3)*** Results for an UNinherited __CLASS__ implementation
***';
echo 'br /ClassName() for TopClass: ' .
TopClass
#37856 [NEW]: Disallow direct parsing of .inc.php includes
From: toomuchphp-phpbugs at yahoo dot com Operating system: PHP version: 5.1.4 PHP Bug Type: Feature/Change Request Bug description: Disallow direct parsing of .inc.php includes Description: Would it be a good idea to provide an option in php.ini to prevent PHP from executing scripts which are designed to be included files? E.g., if PHP detects that the requested document is 'includes/someFile.inc.php' it will refuse to process the document because it has a '.inc.php' extension and is clearly only meant for inclusion. -- Edit bug report at http://bugs.php.net/?id=37856edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37856r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37856r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37856r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37856r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37856r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37856r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37856r=needscript Try newer version:http://bugs.php.net/fix.php?id=37856r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37856r=support Expected behavior:http://bugs.php.net/fix.php?id=37856r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37856r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37856r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37856r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37856r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37856r=dst IIS Stability:http://bugs.php.net/fix.php?id=37856r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37856r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37856r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37856r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37856r=mysqlcfg
#34804 [Opn]: More information about stclass methods
ID: 34804
User updated by: toomuchphp-phpbugs at yahoo dot com
-Summary: More information about class methods
Reported By: toomuchphp-phpbugs at yahoo dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Any
-PHP Version: 5.1.0RC1
+PHP Version: 5.x
New Comment:
So ... now that I have learned C and played around with the 5.1.4
source for a couple of days, I've discovered it's not really possible
to get information about the calling context using matic constants.
In which case, a function named something like 'get_static_child()'
would suffice. I am still trying to figure out how to find the name of
the child class in the Zend hive of structs (if it is actually stored
somewhere). :-S
Previous Comments:
[2006-01-11 21:35:07] kvesteri at cc dot hut dot fi
There should definetly be atleast constant __INHERITED_BY__. This new
constant would allow many wonderful things like a generic singleton
class and an efficient implementation of the martin fowler's Active
Record pattern.
[2005-10-10 10:12:46] toomuchphp-phpbugs at yahoo dot com
Description:
Inside any class method, there are as many as 3 related class and it
would be useful to have all of them as magic constants, and also in the
debug_backtrace function.
Currently only __CLASS__ is available (the name of the direct owner of
the method). It would be good to know the name of the child class (if
the method was called as part of a child class), and the name of the
calling class if the method was called statically (the same as
get_class($this) inside a static method).
This information would be most useful in the debug_backtrace() array.
debug_backtrace() was recently modified to report the direct owner
class name rather than the inheriting class' name (see bug #30828) but
it would really be more helpful in debugging to have all three possible
class names available.
Reproduce code:
---
class A {
function A() {
echo 'direct owner: '.__CLASS__.\n;
echo 'called as part of: '.__INHERITED_BY__.\n;
echo 'called by instance of: '.__STATIC_CALLER__.\n;
}
}
class B extends A { }
class C {
function __construct() {
B::A();
}
}
new C();
Expected result:
direct owner: A
called as part of: B
called by instance of: C
--
Edit this bug report at http://bugs.php.net/?id=34804edit=1
#34804 [NEW]: More information about class methods
From: toomuchphp-phpbugs at yahoo dot com
Operating system: Any
PHP version: 5.1.0RC1
PHP Bug Type: Feature/Change Request
Bug description: More information about class methods
Description:
Inside any class method, there are as many as 3 related class and it would
be useful to have all of them as magic constants, and also in the
debug_backtrace function.
Currently only __CLASS__ is available (the name of the direct owner of the
method). It would be good to know the name of the child class (if the
method was called as part of a child class), and the name of the calling
class if the method was called statically (the same as get_class($this)
inside a static method).
This information would be most useful in the debug_backtrace() array.
debug_backtrace() was recently modified to report the direct owner class
name rather than the inheriting class' name (see bug #30828) but it would
really be more helpful in debugging to have all three possible class names
available.
Reproduce code:
---
class A {
function A() {
echo 'direct owner: '.__CLASS__.\n;
echo 'called as part of: '.__INHERITED_BY__.\n;
echo 'called by instance of: '.__STATIC_CALLER__.\n;
}
}
class B extends A { }
class C {
function __construct() {
B::A();
}
}
new C();
Expected result:
direct owner: A
called as part of: B
called by instance of: C
--
Edit bug report at http://bugs.php.net/?id=34804edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34804r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34804r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34804r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34804r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34804r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34804r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34804r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34804r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34804r=support
Expected behavior: http://bugs.php.net/fix.php?id=34804r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34804r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34804r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34804r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34804r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34804r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34804r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34804r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34804r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34804r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34804r=mysqlcfg
