[PHP-BUG] Bug #52330 [NEW]: __construct() method should always return a new instance
From:
Operating system:
PHP version: Irrelevant
Package: Class/Object related
Bug Type: Bug
Bug description:__construct() method should always return a new instance
Description:
Please see the test script. This should be normal PHP 5.3 class with a good
OOP design.
In PHP it is possible, that I can call the constructor multiple times, for
example:
$person = new \My\Person('Jens', 'Mander');
echo sprintf('Name: %s %s', $person-getName(), $person-getSurname()); //
Will output Name: Jens Mander
$person-__construct('John', 'Doe');
echo sprintf('Name: %s %s', $person-getName(), $person-getSurname()); //
Will output Name: John Doe
In my understanding, it is unexpected, that
1) you can access the constructor method in an instantiated object. The
constructor should only instantiate the object - when you have the object,
there is no need to call it again. If you need something to reset your
object state, you should implement such a method.
2) If you can call the constructor again, that it will change the object
and *not* return a new instance.
For example:
If you add a return new \stdClass(); line to your constructor, it will
still change the instance you called it from, but now it will also return a
stdClass - that's inconsistent, isn't it?
Test script:
---
?php
namespace My;
class Person
{
protected $_name = null;
protected $_surname = null;
/**
* Constructor.
*
* @param string OPTIONAL $name
* @param string OPTIONAL $surname
* @return \My\Person
*/
public function __construct($name = null, $surname = null)
{
if ($name !== null)
{
$this-setName($name);
}
if ($surname !== null)
{
$this-setSurname($surname);
}
}
/**
* Returns the name.
*
* @return null|string Null, when no name was set
*/
public function getName()
{
return $this-_name;
}
/**
* Returns the surname.
*
* @return null|string Null, when no name was set
*/
public function getSurname()
{
return $this-_surname;
}
/**
* Set the name.
*
* @param string $name
* @return \My\Person Provides fluent interface
* @throws \Exception
*/
public function setName($name)
{
if (!is_string($name) || empty($name))
{
throw new \Exception('Name cannot be empty and must be a string!');
}
$this-_name = $name;
return $this;
}
/**
* Set the surname.
*
* @param string $name
* @return \My\Person Provides fluent interface
* @throws \Exception When $name isn't a string or empty
*/
public function setSurname($name)
{
if (!is_string($name) || empty($name))
{
throw new \Exception('Name cannot be empty and must be a string!');
}
$this-_surname = $name;
return $this;
}
}
Expected result:
- FATAL error e.g. Object already constructed!
- The __construct() call should return a *new* object.
Actual result:
--
The __construct() method will work on the object, from where you called it.
--
Edit bug report at http://bugs.php.net/bug.php?id=52330edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52330r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52330r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52330r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52330r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52330r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52330r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52330r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52330r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52330r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52330r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52330r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52330r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52330r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52330r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52330r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52330r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52330r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52330r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52330r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52330r=nozend
Bug #52330 [Wfx]: __construct() method should always return a new instance
Edit report at http://bugs.php.net/bug.php?id=52330edit=1
ID: 52330
User updated by: whistl0r+phpbug at googlemail dot com
Reported by: whistl0r+phpbug at googlemail dot com
Summary: __construct() method should always return a new
instance
Status: Wont fix
Type:Bug
Package: Class/Object related
PHP Version: Irrelevant
New Comment:
Basically, if you don't want __construct() to act like a method call,
don't call it like a method call.
Well, why does PHP supports different visibilities like public,
protected or private? You can tell the programmer, don't read the
variable, it's private! like you say don't call it like a method. ;)
You support it, because it is part of the OOP concept (encapsulation).
Other languages like Java or C# doesn't allow you to call the
constructor like a method. The constructor is only callable with new
(because it's not a normal method).
Currently, to be safe from OOP view, it seems to me like you must add
something like
protected $_initiated = false
to your class. If this is true, your constructor method will end. This
would make sure, that the constructor will only run once and you object
cannot enter an unexpected state, because someone calls the constructor
again...
Previous Comments:
[2010-07-13 18:34:08] ahar...@php.net
That might seem odd, but it seems consistent enough to me. It breaks
down one of two ways:
1. You call the constructor by instantiating an object with new. It
behaves like a constructor -- return values are ignored and a new object
instance is created.
2. You call the constructor by calling $object-__construct(). It
behaves like a method call, including return values being returned.
Basically, if you don't want __construct() to act like a method call,
don't call it like a method call.
[2010-07-13 16:35:38] whistl0r+phpbug at googlemail dot com
Description:
Please see the test script. This should be normal PHP 5.3 class with a
good OOP design.
In PHP it is possible, that I can call the constructor multiple times,
for example:
$person = new \My\Person('Jens', 'Mander');
echo sprintf('Name: %s %s', $person-getName(), $person-getSurname());
// Will output Name: Jens Mander
$person-__construct('John', 'Doe');
echo sprintf('Name: %s %s', $person-getName(), $person-getSurname());
// Will output Name: John Doe
In my understanding, it is unexpected, that
1) you can access the constructor method in an instantiated object. The
constructor should only instantiate the object - when you have the
object, there is no need to call it again. If you need something to
reset your object state, you should implement such a method.
2) If you can call the constructor again, that it will change the object
and *not* return a new instance.
For example:
If you add a return new \stdClass(); line to your constructor, it will
still change the instance you called it from, but now it will also
return a stdClass - that's inconsistent, isn't it?
Test script:
---
?php
namespace My;
class Person
{
protected $_name = null;
protected $_surname = null;
/**
* Constructor.
*
* @param string OPTIONAL $name
* @param string OPTIONAL $surname
* @return \My\Person
*/
public function __construct($name = null, $surname = null)
{
if ($name !== null)
{
$this-setName($name);
}
if ($surname !== null)
{
$this-setSurname($surname);
}
}
/**
* Returns the name.
*
* @return null|string Null, when no name was set
*/
public function getName()
{
return $this-_name;
}
/**
* Returns the surname.
*
* @return null|string Null, when no name was set
*/
public function getSurname()
{
return $this-_surname;
}
/**
* Set the name.
*
* @param string $name
* @return \My\Person Provides fluent interface
* @throws \Exception
*/
public function setName($name)
{
if (!is_string($name) || empty($name))
{
throw new \Exception('Name cannot be empty and must be a
string!');
}
$this-_name = $name;
return $this;
}
/**
* Set the surname.
*
* @param string $name
* @return \My\Person Provides fluent interface
* @throws \Exception When $name isn't a string or empty
*/
public function setSurname($name)
{
if (!is_string($name) || empty($name))
{
throw new \Exception('Name cannot be empty and must be a
string!');
}
$this-_surname = $name;
return $this;
}
}
Expected result:
- FATAL error e.g. Object already constructed!
- The __construct() call should return a *new* object
Req #45586 [Com]: php_mbstring must be loaded before php_exif extension in php.ini
Edit report at http://bugs.php.net/bug.php?id=45586edit=1 ID: 45586 Comment by: whistl0r+phpbug at googlemail dot com Reported by: bouke at haarsma dot eu Summary: php_mbstring must be loaded before php_exif extension in php.ini Status: Open Type: Feature/Change Request Package: Feature/Change Request Operating System: Windows XP PHP Version: 5.2.6 New Comment: This problem also affects PHP 5.3 (tested against the latest 5.3.2 release for Windows). If you cannot change the order (I agree missingno's argumentation), this should be documented! Google for the term php_exif not found, you will find many reports like http://eligeske.com/wordpress/php_exif-dll-the-specified-module-could-not-be- found/ Previous Comments: [2008-07-23 09:54:31] missingno at ifrance dot com I guess the problem comes from the fact that the extension entries are sorted by alphabetical order in the php.ini file. Correcting the order of extensions would solve the problem but would require a lot of testing because I think this problem also occurs with other extensions as well... I don't think it is such a good idea because the way the list is currently written makes it easy to find the extensions you want to activate. Also, each extension's page in the manual clearly has some sort of a FAQ regarding installation/configuration. The only problem I seen then is users that do not read the manual, but I digress... Anyway, I think this is a WONTFIX for now. One possible solution would be for extensions to manage dependancies at runtime and let the user know the steps to follow in order for the extension to work. But this would probably put to much of a burden on the developpers compared to the actual gain. [2008-07-21 17:30:45] j...@php.net Better summary. There's no crash here. [2008-07-21 17:17:19] bouke at haarsma dot eu Description: Please see: http://bugs.php.net/bug.php?id=27248 Also see: http://bugs.php.net/bug.php?id=32552 Using the latest php.ini files, the problem still exists. The default order for loading the extensions is wrong and error-prone. The 'solution' as stated in the comments should also be reflected in the php.ini-file. Please note that this has been solved in 2005, but the bug is introduced again. Reproduce code: --- Enter this into php.ini: extension=php_exif.dll extension=php_mbstring.dll Solution: extension=php_mbstring.dll extension=php_exif.dll (Swaped order) Expected result: -no error message- Actual result: -- -error message: php_mbstring.dll not found -- Edit this bug report at http://bugs.php.net/bug.php?id=45586edit=1
[PHP-BUG] Bug #51952 [NEW]: __FILE__ and dirname() are returning wrong pathes when working with junctions
From: Operating system: Windows Vista/7 PHP version: 5.2.13 Package: Directory function related Bug Type: Bug Bug description:__FILE__ and dirname() are returning wrong pathes when working with junctions Description: Consister the following setup: You keep your source code in C:\Repositories\example.org\trunk. You just point your DOCUMENT_ROOT to that folder via symlink/junction: httpd.conf: [...] DOCUMENT_ROOT C:\Sites\example.org\htdocs [...] C:\Sites\example.orgdir Volume in drive D is System Volume Serial Number is E49D-A2E7 Directory of C:\Sites\example.org 2010-05-31 01:08DIR . 2010-05-31 01:08DIR .. 2010-05-31 01:08JUNCTION htdocs [C:\Repositories\example.org\trunk] You now run the script C:\Sites\example.org\htdocs\test.php. Test script: --- ?php echo 'File: ' . __FILE__ . PHP_EOL; echo 'Dir: ' . dirname(__FILE__) . PHP_EOL; Expected result: File: C:\Repositories\example.org\trunk\test.php Dir: C:\Repositories\example.org\trunk Actual result: -- File: C:\Sites\example.org\htdocs\test.php Dir: C:\Sites\example.org\htdocs -- Edit bug report at http://bugs.php.net/bug.php?id=51952edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51952r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51952r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=51952r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=51952r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51952r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51952r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51952r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51952r=needscript Try newer version: http://bugs.php.net/fix.php?id=51952r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51952r=support Expected behavior: http://bugs.php.net/fix.php?id=51952r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51952r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51952r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51952r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51952r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51952r=dst IIS Stability: http://bugs.php.net/fix.php?id=51952r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51952r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51952r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51952r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51952r=mysqlcfg
Bug #51952 [Com]: __FILE__ and dirname() are returning wrong pathes when working with junctions
Edit report at http://bugs.php.net/bug.php?id=51952edit=1 ID: 51952 Comment by: whistl0r+phpbug at googlemail dot com Reported by: whistl0r+phpbug at googlemail dot com Summary: __FILE__ and dirname() are returning wrong pathes when working with junctions Status: Open Type: Bug Package: Directory function related Operating System: Windows Vista/7 PHP Version: 5.2.13 New Comment: I found this inconsistent behavior, after upgrading to PHP 5.3, because a required once call (required_once realpath(dirname(__FILE__) . '/../configs/main.php');) failed. It failed because PHP 5.3 resolves the symlinks. I checked the documentation and it says that this is the wanted behavior. So it seems like, because it nothing new in PHP 5.3, that it must be a bug in PHP 5.2. Previous Comments: [2010-05-31 01:39:52] whistl0r+phpbug at googlemail dot com Description: Consister the following setup: You keep your source code in C:\Repositories\example.org\trunk. You just point your DOCUMENT_ROOT to that folder via symlink/junction: httpd.conf: [...] DOCUMENT_ROOT C:\Sites\example.org\htdocs [...] C:\Sites\example.orgdir Volume in drive D is System Volume Serial Number is E49D-A2E7 Directory of C:\Sites\example.org 2010-05-31 01:08DIR . 2010-05-31 01:08DIR .. 2010-05-31 01:08JUNCTION htdocs [C:\Repositories\example.org\trunk] You now run the script C:\Sites\example.org\htdocs\test.php. Test script: --- ?php echo 'File: ' . __FILE__ . PHP_EOL; echo 'Dir: ' . dirname(__FILE__) . PHP_EOL; Expected result: File: C:\Repositories\example.org\trunk\test.php Dir: C:\Repositories\example.org\trunk Actual result: -- File: C:\Sites\example.org\htdocs\test.php Dir: C:\Sites\example.org\htdocs -- Edit this bug report at http://bugs.php.net/bug.php?id=51952edit=1
[PHP-BUG] Bug #51953 [NEW]: realpath isn't resolving symlinks/junctions
From: Operating system: Windows Vista/7 PHP version: 5.2.13 Package: Directory function related Bug Type: Bug Bug description:realpath isn't resolving symlinks/junctions Description: This bug is maybe related to http://bugs.php.net/bug.php?id=51952 Your in your httpd.conf configured DOCUMENT_ROOT is C:\Sites\example.org\htdocs. But this isn't a folder, it's a symlink/junction to the following folder: C:\Foo. Now you call C:\Sites\example.org\htdocs\test.php Test script: --- ?php echo realpath(getcwd()); Expected result: C:\Foo Actual result: -- C:\Sites\example.org\htdocs -- Edit bug report at http://bugs.php.net/bug.php?id=51953edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51953r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51953r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=51953r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=51953r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51953r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51953r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51953r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51953r=needscript Try newer version: http://bugs.php.net/fix.php?id=51953r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51953r=support Expected behavior: http://bugs.php.net/fix.php?id=51953r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51953r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51953r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51953r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51953r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51953r=dst IIS Stability: http://bugs.php.net/fix.php?id=51953r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51953r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51953r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51953r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51953r=mysqlcfg
#47800 [Bgs]: Sessions won't be loaded when Cookies are disabled
ID: 47800
User updated by: whistl0r+phpbug at googlemail dot com
Reported By: whistl0r+phpbug at googlemail dot com
Status: Bogus
Bug Type: Session related
Operating System: Windows
PHP Version: 5.3.0RC1
New Comment:
Please could you say at least why this is bogus?
The example code is identical to your documentation, isn't it?
http://www.php.net/manual/en/session.idpassing.php
Did I miss a new behavior in PHP 5.3?
Previous Comments:
[2009-03-31 07:20:32] j...@php.net
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
[2009-03-27 02:36:36] whistl0r+phpbug at googlemail dot com
Description:
When forcing PHP to not use cookies for sessions, PHP isn't able to
load an existing session. Instead it will create a new one.
Tested with the default php.ini (php.ini-production) coming with the
php-5.3.0RC1-nts-Win32-VC6-x86.zip package.
I just fixed line 428 and set the session.save_path value.
Session files will be created as expected.
With PHP 5.3, the script is working as expected.
I can confirm, that this problem is still present in the latest
snapshot (VC6 x86 Thread Safe (2009-Mar-26 19:00:00)).
Reproduce code:
---
?php
// Disable Cookie-Usage
ini_set('session.use_cookies', 0);
// Start the session
session_start();
if (!isset($_SESSION['counter']))
{
// Initialize SESSION
$_SESSION['counter'] = 1;
}
else
{
// Existing SESSION - Update value
$_SESSION['counter'] = $_SESSION['counter'] + 1;
}
// Print SESSION value
printf('Counter value #%ubr /' . PHP_EOL, $_SESSION['counter']);
// Print Next link
printf('a href=%s?%sNext/a',
$_SERVER['PHP_SELF'],
SID
);
Expected result:
When you first run this code, a session with a variable counter with
the value 1 (int) should be created and a link pointing to the same
script with this SESSION-ID should be displayed.
When you click this link, you run this code again and the previous
created session should be loaded and the counter variable should be
incremented by 1.
Actual result:
--
On every run, PHP creates a new session.
--
Edit this bug report at http://bugs.php.net/?id=47800edit=1
#47834 [NEW]: tempnam() changes to %TEMP% instead of returning false
From: whistl0r+phpbug at googlemail dot com
Operating system: Windows
PHP version: 5.2.9
PHP Bug Type: Filesystem function related
Bug description: tempnam() changes to %TEMP% instead of returning false
Description:
I wanted to check, how tempnam() handles file system limits.
On NTFS, just 65535 files per directory are allowed.
Reproduce code:
---
?php
// Keep script alive
ignore_user_abort(1);
@set_time_limit(0);
$dir = 'C:\Test';
(if (!file_exists($dir))
{
// Create Test directory
mkdir($dir, null, true);
}
$i = 0;
while (tempnam($dir, 'Foobar'))
{
$i++;
}
printf('%u files created', $i);
Expected result:
The script should stop, because tempnam() should return false.
The function should return false, because when 65535 files are in the
specified directory, you reached a limit and aren't able to write to
C:\Test anymore.
Actual result:
--
The script will keep running.
After the 65535. file is created in C:\Test, the function will ignore
the specified directory and switch to %temp% (which is usually
C:\Windows\Temp).
--
Edit bug report at http://bugs.php.net/?id=47834edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47834r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47834r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47834r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47834r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47834r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47834r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47834r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47834r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47834r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47834r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47834r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47834r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47834r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47834r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47834r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47834r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47834r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47834r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47834r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47834r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47834r=mysqlcfg
#47800 [NEW]: Sessions won't be loaded when Cookies are disabled
From: whistl0r+phpbug at googlemail dot com
Operating system: Windows
PHP version: 5.3.0RC1
PHP Bug Type: Session related
Bug description: Sessions won't be loaded when Cookies are disabled
Description:
When forcing PHP to not use cookies for sessions, PHP isn't able to load
an existing session. Instead it will create a new one.
Tested with the default php.ini (php.ini-production) coming with the
php-5.3.0RC1-nts-Win32-VC6-x86.zip package.
I just fixed line 428 and set the session.save_path value.
Session files will be created as expected.
With PHP 5.3, the script is working as expected.
I can confirm, that this problem is still present in the latest snapshot
(VC6 x86 Thread Safe (2009-Mar-26 19:00:00)).
Reproduce code:
---
?php
// Disable Cookie-Usage
ini_set('session.use_cookies', 0);
// Start the session
session_start();
if (!isset($_SESSION['counter']))
{
// Initialize SESSION
$_SESSION['counter'] = 1;
}
else
{
// Existing SESSION - Update value
$_SESSION['counter'] = $_SESSION['counter'] + 1;
}
// Print SESSION value
printf('Counter value #%ubr /' . PHP_EOL, $_SESSION['counter']);
// Print Next link
printf('a href=%s?%sNext/a',
$_SERVER['PHP_SELF'],
SID
);
Expected result:
When you first run this code, a session with a variable counter with the
value 1 (int) should be created and a link pointing to the same script
with this SESSION-ID should be displayed.
When you click this link, you run this code again and the previous created
session should be loaded and the counter variable should be incremented
by 1.
Actual result:
--
On every run, PHP creates a new session.
--
Edit bug report at http://bugs.php.net/?id=47800edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47800r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47800r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47800r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47800r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47800r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47800r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47800r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47800r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47800r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47800r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47800r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47800r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47800r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47800r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47800r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47800r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47800r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47800r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47800r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47800r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47800r=mysqlcfg
