[PHP-DOC] #27573 [Bgs]: fopen mode "r" not working properly

[ib at wupperonline dot de]

 ID:   27573
 User updated by:  ib at wupperonline dot de
 Reported By:  ib at wupperonline dot de
 Status:   Bogus
 Bug Type: Documentation problem
 Operating System: Windows 2000
 PHP Version:  4.3.4
 New Comment:

Why is fopen mode "r" working in binary mode more portable?



It would be more portable if I could use the same mode ("r") on all
platforms - as text mode (which is, for example, what the gcc port for
Windows does as well). There is already a special mode ("rb") for
systems distinguishing between the modes (which is well documented,
even for POSIX fopen, if I remember well). No need for another ("rt")
one.


Previous Comments:


[2004-03-11 13:34:45] [EMAIL PROTECTED]

ah, already documented then :-)



[2004-03-11 13:32:13] [EMAIL PROTECTED]

That is correct; fopen was changed to work in binary mode by default in
order to be more portable.



I thought this was mentioned in the NEWS file, but apparently not.



The change was made in PHP 4.3.2.



The undocumented 't' mode has been a feature of the MSVCRT

since forever.



This stuff needs documenting fairly prominently.





[2004-03-11 13:27:57] [EMAIL PROTECTED]

>From http://www.php.net/fopen



Windows offers a text-mode translation flag ('t') which will
transparently translate \n to \r\n when working with the file. In
contrast, you can also use 'b' to force binary mode, which will not
translate your data. To use these flags, specify either 'b' or 't' as
the last character of the mode parameter. 



As of PHP 4.3.2, the default mode is set to binary for all platforms
that distinguish between binary and text mode. If you are having
problems with your scripts after upgrading, try using the 't' flag as a
workaround until you have made your script more portable as mentioned
above. 







[2004-03-11 12:31:46] ib at wupperonline dot de

Description:

Using mode "r" to fopen files under Windows doesn't open them in text
mode (as it should), but in binary mode, thus working exactly like
"rb". Reading these files, you'll get "\r\n" instead of "\n" for new
line character.



Surprisingly, fopen accepts mode "rt" which isn't documented but works
as "r" should. It opens in text mode and returns "\n" instead of
"\r\n".

Reproduce code:
---
Create a file named dat.txt containing 4 bytes: "1", CR, LF, "2", LF.



$f = fopen("dat.txt", "r");



$d = fread($f, 1);

echo ord($d) . " ";

$d = fread($f, 1);

echo ord($d) . " ";

$d = fread($f, 1);

echo ord($d) . " ";

$d = fread($f, 1);

echo ord($d) . " ";



fclose($f);

Expected result:

49 10 50 10

Actual result:
--
49 13 10 50





-- 
Edit this bug report at http://bugs.php.net/?id=27573&edit=1

[PHP-DOC] #27575 [Opn->Bgs]: ftell reports the size of appended bytes instead of the file pointer position

[wez]

 ID:   27575
 Updated by:   [EMAIL PROTECTED]
 Reported By:  fbernardi at bbros dot it
-Status:   Open
+Status:   Bogus
-Bug Type: Filesystem function related
+Bug Type: Documentation problem
 Operating System: Red Hat Linux
 PHP Version:  4.3.4
 New Comment:

Duplicate of Bug #24071.

You cannot rely on ftell() or fseek() when working with an append-only
stream.


Previous Comments:


[2004-03-11 14:33:10] fbernardi at bbros dot it

Description:

ftell() reports the size of bytes added to a file instead of the
position of the file pointer in the file.

I guess this behavior is reproduceable only on appending data to a
file, since on new files the file pointer position is at the same place
of the number of bytes added.

Reproduce code:
---




Expected result:

The pointer should be at the position 8, but ftell reports 8

Actual result:
--
The pointer should be at the position 8, but ftell reports 4





-- 
Edit this bug report at http://bugs.php.net/?id=27575&edit=1

Re: [PHP-DOC] statistics

[Nuno Lopes]

> > > so can you give us your url ? :)
> > Mine stats don't have graphs or so. Just raw data.
> > Top commiters: http://testes.aborla.net/top.html
> > Zero commits: http://testes.aborla.net/zero.html
>
> Must be something wrong with those, as I'm not listed in any file.
>
> Derick


Sorry Derick...

I've only collected the CVS account that are listed under phpdoc team in
CVSROOT. I've not added the developpers.
This was because there are too many cvs account and the program needs to do
lots of connections to the bonsai server. Just to keep systems guys happy
(or not too angry..)


Nuno

[PHP-DOC] #27573 [Opn->Bgs]: fopen mode "r" not working properly

[wez]

 ID:   27573
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ib at wupperonline dot de
-Status:   Open
+Status:   Bogus
 Bug Type: Documentation problem
 Operating System: Windows 2000
 PHP Version:  4.3.4
 New Comment:

ah, already documented then :-)


Previous Comments:


[2004-03-11 13:32:13] [EMAIL PROTECTED]

That is correct; fopen was changed to work in binary mode by default in
order to be more portable.



I thought this was mentioned in the NEWS file, but apparently not.



The change was made in PHP 4.3.2.



The undocumented 't' mode has been a feature of the MSVCRT

since forever.



This stuff needs documenting fairly prominently.





[2004-03-11 13:27:57] [EMAIL PROTECTED]

>From http://www.php.net/fopen



Windows offers a text-mode translation flag ('t') which will
transparently translate \n to \r\n when working with the file. In
contrast, you can also use 'b' to force binary mode, which will not
translate your data. To use these flags, specify either 'b' or 't' as
the last character of the mode parameter. 



As of PHP 4.3.2, the default mode is set to binary for all platforms
that distinguish between binary and text mode. If you are having
problems with your scripts after upgrading, try using the 't' flag as a
workaround until you have made your script more portable as mentioned
above. 







[2004-03-11 12:31:46] ib at wupperonline dot de

Description:

Using mode "r" to fopen files under Windows doesn't open them in text
mode (as it should), but in binary mode, thus working exactly like
"rb". Reading these files, you'll get "\r\n" instead of "\n" for new
line character.



Surprisingly, fopen accepts mode "rt" which isn't documented but works
as "r" should. It opens in text mode and returns "\n" instead of
"\r\n".

Reproduce code:
---
Create a file named dat.txt containing 4 bytes: "1", CR, LF, "2", LF.



$f = fopen("dat.txt", "r");



$d = fread($f, 1);

echo ord($d) . " ";

$d = fread($f, 1);

echo ord($d) . " ";

$d = fread($f, 1);

echo ord($d) . " ";

$d = fread($f, 1);

echo ord($d) . " ";



fclose($f);

Expected result:

49 10 50 10

Actual result:
--
49 13 10 50





-- 
Edit this bug report at http://bugs.php.net/?id=27573&edit=1

[PHP-DOC] #27573 [Bgs->Opn]: fopen mode "r" not working properly

[wez]

 ID:   27573
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ib at wupperonline dot de
-Status:   Bogus
+Status:   Open
-Bug Type: Filesystem function related
+Bug Type: Documentation problem
 Operating System: Windows 2000
 PHP Version:  4.3.4
 New Comment:

That is correct; fopen was changed to work in binary mode by default in
order to be more portable.



I thought this was mentioned in the NEWS file, but apparently not.



The change was made in PHP 4.3.2.



The undocumented 't' mode has been a feature of the MSVCRT

since forever.



This stuff needs documenting fairly prominently.




Previous Comments:


[2004-03-11 13:27:57] [EMAIL PROTECTED]

>From http://www.php.net/fopen



Windows offers a text-mode translation flag ('t') which will
transparently translate \n to \r\n when working with the file. In
contrast, you can also use 'b' to force binary mode, which will not
translate your data. To use these flags, specify either 'b' or 't' as
the last character of the mode parameter. 



As of PHP 4.3.2, the default mode is set to binary for all platforms
that distinguish between binary and text mode. If you are having
problems with your scripts after upgrading, try using the 't' flag as a
workaround until you have made your script more portable as mentioned
above. 







[2004-03-11 12:31:46] ib at wupperonline dot de

Description:

Using mode "r" to fopen files under Windows doesn't open them in text
mode (as it should), but in binary mode, thus working exactly like
"rb". Reading these files, you'll get "\r\n" instead of "\n" for new
line character.



Surprisingly, fopen accepts mode "rt" which isn't documented but works
as "r" should. It opens in text mode and returns "\n" instead of
"\r\n".

Reproduce code:
---
Create a file named dat.txt containing 4 bytes: "1", CR, LF, "2", LF.



$f = fopen("dat.txt", "r");



$d = fread($f, 1);

echo ord($d) . " ";

$d = fread($f, 1);

echo ord($d) . " ";

$d = fread($f, 1);

echo ord($d) . " ";

$d = fread($f, 1);

echo ord($d) . " ";



fclose($f);

Expected result:

49 10 50 10

Actual result:
--
49 13 10 50





-- 
Edit this bug report at http://bugs.php.net/?id=27573&edit=1

Re: [PHP-DOC] statistics

[Derick Rethans]

On Thu, 11 Mar 2004, Nuno Lopes wrote:

> > so can you give us your url ? :)
> Mine stats don't have graphs or so. Just raw data.
> Top commiters: http://testes.aborla.net/top.html
> Zero commits: http://testes.aborla.net/zero.html

Must be something wrong with those, as I'm not listed in any file.

Derick

[PHP-DOC] #27574 [NEW]: Bugs in example 2 of xml documentation

[stevenv at optonline dot net]

From: stevenv at optonline dot net
Operating system: 
PHP version:  Irrelevant
PHP Bug Type: Documentation problem
Bug description:  Bugs in example 2 of xml documentation

Description:

There are two similar problems in the functions startElement() and
endElement() in example 2 on .



1) $htmltag, which springs into existence out of nowhere, is being used in
a comparison. I think it was meant to be $name rather than $htmltag.



2) I think the following lines:



   if ($htmltag == $map_array[$name]) {

   echo "<$htmltag>";



should be:



   if ( isset($map_array[$name]) ) {

   echo "<$map_array[$name]>";



Otherwise the output will be identical to the input (no conversion).


-- 
Edit bug report at http://bugs.php.net/?id=27574&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27574&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27574&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27574&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27574&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27574&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27574&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27574&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27574&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27574&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27574&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27574&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27574&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27574&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27574&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27574&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27574&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27574&r=float

Re: [PHP-DOC] statistics

[Nuno Lopes]

> so can you give us your url ? :)
Mine stats don't have graphs or so. Just raw data.
Top commiters: http://testes.aborla.net/top.html
Zero commits: http://testes.aborla.net/zero.html


Source: http://testes.aborla.net/stats.zip


> > So, why not delete them?
> 
> erm, I'm not sure you want to start this war .. :)
> 

Not a war, just justice :)

Nuno

Re: [PHP-DOC] statistics

[Mehdi Achour]

Nuno Lopes wrote:
Someone else has done a similar analysis before:

http://libresoft.dat.escet.urjc.es/cvsanal/php-cvs/index.php?menu=Index

in particular:


http://libresoft.dat.escet.urjc.es/cvsanal/php-cvs/index.php?menu=Modules&module=phpdoc

These are a bit old.
so can you give us your url ? :)


And it is not strange the many do not commit, a good
number have a php.net account for show ;-). Similar
statistics can be seen for PHP, PEAR, etc.


So, why not delete them?
erm, I'm not sure you want to start this war .. :)

didou

Re: [PHP-DOC] statistics

[Nuno Lopes]

> Someone else has done a similar analysis before:
>
> http://libresoft.dat.escet.urjc.es/cvsanal/php-cvs/index.php?menu=Index
>
> in particular:
>
>
http://libresoft.dat.escet.urjc.es/cvsanal/php-cvs/index.php?menu=Modules&module=phpdoc

These are a bit old.


> And it is not strange the many do not commit, a good
> number have a php.net account for show ;-). Similar
> statistics can be seen for PHP, PEAR, etc.

So, why not delete them?


> If you are interested, contact them and perhaps you
> can help keep an up-to-date stats (if there is a
> need/interest).
>
> Cheers.
> =
> --- Jesus M. Castagnetto <[EMAIL PROTECTED]>

Re: [PHP-DOC] assert_options() - documentation error?

[Nuno Lopes]

Nop, the manual is right!

Nuno


- Original Message - 
From: "Cornelia Boenigk" <[EMAIL PROTECTED]>
To: "PHPdoc" <[EMAIL PROTECTED]>
Sent: Wednesday, March 10, 2004 8:01 PM
Subject: [PHP-DOC] assert_options() - documentation error?


> Hi
> 
> the manual writes: 
> assert_options() will return the original setting of any option or
> FALSE on errors.
> 
> A call on assert_options() returns
> 
> Warning: Wrong parameter count for assert_options() in
> c:\apache\htdocs\info.php5 on line 2
> 
> Tested with PHP 4 and PHP 5.
> 
> Regards
> 
> Conni

RE: [PHP-DOC] cvs: phpdoc /en/reference/mysqli/functions mysqli-connect.xml

[Enrique Garcia Briones]

Hi Georg

I have change the function, maybe you would like to review it. :D

Enrique García Briones

>Hello Enrique,
>
>your changes are wrong - you should change the parameter in
> 
>from hostname to host (my failure :( ). Paramter host can be hostname
or ip 
>address, so the name host is correct.
>
>Cheers
>
>Georg

[PHP-DOC] cvs: phpdoc /en/reference/mysqli/functions mysqli-connect.xml

[Enrique Garcia Briones]

baoengb Thu Mar 11 09:23:07 2004 EDT

  Modified files:  
/phpdoc/en/reference/mysqli/functions   mysqli-connect.xml 
  Log:
  As I said, the parameter in the description should be alwas host
  
http://cvs.php.net/diff.php/phpdoc/en/reference/mysqli/functions/mysqli-connect.xml?r1=1.12&r2=1.13&ty=u
Index: phpdoc/en/reference/mysqli/functions/mysqli-connect.xml
diff -u phpdoc/en/reference/mysqli/functions/mysqli-connect.xml:1.12 
phpdoc/en/reference/mysqli/functions/mysqli-connect.xml:1.13
--- phpdoc/en/reference/mysqli/functions/mysqli-connect.xml:1.12Wed Mar 10 
15:47:04 2004
+++ phpdoc/en/reference/mysqli/functions/mysqli-connect.xml Thu Mar 11 09:23:06 
2004
@@ -1,5 +1,5 @@
 
-
+
   

 mysqli_connect
@@ -11,7 +11,7 @@
 Procedural style
 
  objectmysqli_connect
- stringhostname
+ stringhost
  stringusername
  stringpasswd
  stringdbname
@@ -23,7 +23,7 @@
 mysqli
  
   __construct
-  stringhostname
+  stringhost
   stringusername
   stringpasswd
   stringdbname
@@ -33,7 +33,7 @@
 
 
  The mysqli_connect function attempts to open a connection 
to the MySQL Server 
- running on hostname which can be either a host name or an 
IP address. Passing the
+ running on host which can be either a host name or an IP 
address. Passing the
  &null; value or the string "localhost" to this parameter, the local host is 
assumed. When possible, 
  pipes will be used instead of the TCP/IP protocol. If successful, the 
mysqli_connect
  will return an object  representing the connection to the database, or &false; 
on failure.
@@ -51,7 +51,7 @@
 
 
  The port and socket parameters are 
used in
- conjunction with the hostname parameter to further 
control how to connect
+ conjunction with the host parameter to further control 
how to connect
  to the database server. The port parameter specifies the 
port number to
  attempt to connect to the MySQL server on, while the 
socket parameter
  specifies the socket or named pipe that should be used. 
@@ -60,7 +60,7 @@
  
   Specifying the socket parameter will not explicitly 
determine the type
   of connection to be used when connecting to the MySQL server. How the 
connection is made to the
-  MySQL database is determined by the hostname parameter.
+  MySQL database is determined by the host parameter.
  
 

RE: [PHP-DOC] Can't connect mysql to php.

[Enrique Garcia Briones]

Hi, 

First of all, people said that this is not the right place to ask
general questions, please refer to [EMAIL PROTECTED]

But you can check that the logs should be at /var/loh/httpd/*.err, and
also
You can have a look at your php.ini in the error reporting section.

Regards

Enrique García Briones


-Mensaje original-
De: James Applebaum [mailto:[EMAIL PROTECTED] 
Enviado el: Miércoles, 10 de Marzo de 2004 07:52 p.m.
Para: [EMAIL PROTECTED]
Asunto: [PHP-DOC] Can't connect mysql to php.

Mysql working fine & so is PHP.

But when I try to connect to the mysql table from within browser I get 
nothing.  Additionally I can't locate a log to tell me what is 
happening.

The sock an port is defined in both the my.conf and the php.ini.
Thoughts?

PHP 4.1.2 and mysql 4.0.17

my.conf
count 0
force FALSE
compress  FALSE
character-sets-dir(No default value)
host  (No default value)
port  3306
relative  FALSE
socket/var/lib/mysql/mysql.sock
sleep 0
user  root
verbose   FALSE
vertical  FALSE
connect_timeout   43200
shutdown_timeout  3600

php.ini
mysql.default_port = 3306
mysql.default_socket = /var/lib/mysql/mysql.sock
mysql.default_host = localhost

[PHP-DOC] cvs: phpdoc /en/reference/tidy configure.xml

[Mehdi Achour]

didou   Thu Mar 11 07:51:28 2004 EDT

  Modified files:  
/phpdoc/en/reference/tidy   configure.xml 
  Log:
  using option
  
http://cvs.php.net/diff.php/phpdoc/en/reference/tidy/configure.xml?r1=1.5&r2=1.6&ty=u
Index: phpdoc/en/reference/tidy/configure.xml
diff -u phpdoc/en/reference/tidy/configure.xml:1.5 
phpdoc/en/reference/tidy/configure.xml:1.6
--- phpdoc/en/reference/tidy/configure.xml:1.5  Wed Mar 10 12:16:34 2004
+++ phpdoc/en/reference/tidy/configure.xml  Thu Mar 11 07:51:27 2004
@@ -1,5 +1,5 @@
 
-
+
 
  &reftitle.install;
  
@@ -37,8 +37,8 @@
   from &url.pecl.get.win;.
  
  
-  In PHP 5 you need only to compile using the --with-tidy
-  option.
+  In PHP 5 you need only to compile using the --with-tidy option.
  
 
 

[PHP-DOC] #27564 [WFx]: list behavior

[bolk at hitv dot ru]

 ID:   27564
 User updated by:  bolk at hitv dot ru
 Reported By:  bolk at hitv dot ru
 Status:   Wont fix
 Bug Type: Documentation problem
 Operating System: Windows ME
 PHP Version:  4.3.4
 New Comment:

Funny side effect :)) By the way this behavior may cause some problem:



function Test()

{

  $res = some_user_func();

  return count($res) == 1 ? $res[0] : $res;

}

list ($a) = Test();



If some_user_func returns "array(1,2)" then $a will contains '1' but if
it returns array('Test') then $a will contains 'T'.



I think it will be better if PHP cause notice or something in this way
or make right type conversion.


Previous Comments:


[2004-03-11 05:15:06] [EMAIL PROTECTED]

It's a side affect, I don't think we should document this :-) (Also,
don't rely on this behavior)



[2004-03-11 04:49:35] bolk at hitv dot ru

Description:

This is correct but no record in documentation:



$test = 'Test';

list ($a, $b) = $test;

echo $a.$b;

Reproduce code:
---
$test = 'Test';

list ($a, $b) = $test;

echo $a.$b;

Expected result:

it prints: Te






-- 
Edit this bug report at http://bugs.php.net/?id=27564&edit=1

[PHP-DOC] #27564 [Opn->WFx]: list behavior

[derick]

 ID:   27564
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bolk at hitv dot ru
-Status:   Open
+Status:   Wont fix
 Bug Type: Documentation problem
 Operating System: Windows ME
 PHP Version:  4.3.4
 New Comment:

It's a side affect, I don't think we should document this :-) (Also,
don't rely on this behavior)


Previous Comments:


[2004-03-11 04:49:35] bolk at hitv dot ru

Description:

This is correct but no record in documentation:



$test = 'Test';

list ($a, $b) = $test;

echo $a.$b;

Reproduce code:
---
$test = 'Test';

list ($a, $b) = $test;

echo $a.$b;

Expected result:

it prints: Te






-- 
Edit this bug report at http://bugs.php.net/?id=27564&edit=1

[PHP-DOC] #27564 [NEW]: list behavior

[bolk at hitv dot ru]

From: bolk at hitv dot ru
Operating system: Windows ME
PHP version:  4.3.4
PHP Bug Type: Documentation problem
Bug description:  list behavior

Description:

This is correct but no record in documentation:



$test = 'Test';

list ($a, $b) = $test;

echo $a.$b;

Reproduce code:
---
$test = 'Test';

list ($a, $b) = $test;

echo $a.$b;

Expected result:

it prints: Te


-- 
Edit bug report at http://bugs.php.net/?id=27564&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27564&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27564&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27564&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27564&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27564&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27564&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27564&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27564&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27564&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27564&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27564&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27564&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27564&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27564&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27564&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27564&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27564&r=float

[PHP-DOC] #27555 [Bgs->Opn]: Unable to modify $_SESSION from __destruct()

[derick]

 ID:   27555
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jaanus at heeringson dot com
-Status:   Bogus
+Status:   Open
 Bug Type: Documentation problem
 Operating System: Linux 2.4.24
 PHP Version:  5CVS-2004-03-10 (dev)
 New Comment:

It's still not documented, leave it as an open doc bug.


Previous Comments:


[2004-03-11 04:28:32] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The destructor is executed too late in the shutdown sequence. If you
want a destructor to modify some $_SESSION

then you need to manually refcount and free all references using
unset() before the script terminates.



[2004-03-11 03:16:29] [EMAIL PROTECTED]

Destructors are run (when not unset-ing yourself) after the session
module finalizes the session so everything done in constructors has no
effect. I agree it's not optimal behavior, but I don't think we need to
classify it as a bug. It is not documented though so I'm making this a
documentation problem.



[2004-03-11 02:35:15] jaanus at heeringson dot com

Yes, but that is not the issue here, is it? What this bug is about is
the unability to add session variables from __destruct(). Obviously you
have to reload the page to se the effect on the real session. The
[destructor] => Yes will NEVER appear in $_SESSION.



[2004-03-10 19:50:59] [EMAIL PROTECTED]

If you put something like "echo 'this happens now';" line in the
__destruct() call you will see that it's executed AFTER your print_r()
line. This is correct behaviour.





[2004-03-10 18:42:06] jaanus at heeringson dot com

Description:

Unable to add session variables from the __destruct() handler in a
class. The $_SESSION variable can be accessed and viewed in the
__destruct() handler though.

Reproduce code:
---






Expected result:

Array

(

[destructor] => Yes

[working] => Yes

)

Actual result:
--
Array

(

[working] => Yes

)





-- 
Edit this bug report at http://bugs.php.net/?id=27555&edit=1

[PHP-DOC] #27555 [Opn->Bgs]: Unable to modify $_SESSION from __destruct()

[helly]

 ID:   27555
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jaanus at heeringson dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Documentation problem
 Operating System: Linux 2.4.24
 PHP Version:  5CVS-2004-03-10 (dev)
 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The destructor is executed too late in the shutdown sequence. If you
want a destructor to modify some $_SESSION

then you need to manually refcount and free all references using
unset() before the script terminates.


Previous Comments:


[2004-03-11 03:16:29] [EMAIL PROTECTED]

Destructors are run (when not unset-ing yourself) after the session
module finalizes the session so everything done in constructors has no
effect. I agree it's not optimal behavior, but I don't think we need to
classify it as a bug. It is not documented though so I'm making this a
documentation problem.



[2004-03-11 02:35:15] jaanus at heeringson dot com

Yes, but that is not the issue here, is it? What this bug is about is
the unability to add session variables from __destruct(). Obviously you
have to reload the page to se the effect on the real session. The
[destructor] => Yes will NEVER appear in $_SESSION.



[2004-03-10 19:50:59] [EMAIL PROTECTED]

If you put something like "echo 'this happens now';" line in the
__destruct() call you will see that it's executed AFTER your print_r()
line. This is correct behaviour.





[2004-03-10 18:42:06] jaanus at heeringson dot com

Description:

Unable to add session variables from the __destruct() handler in a
class. The $_SESSION variable can be accessed and viewed in the
__destruct() handler though.

Reproduce code:
---






Expected result:

Array

(

[destructor] => Yes

[working] => Yes

)

Actual result:
--
Array

(

[working] => Yes

)





-- 
Edit this bug report at http://bugs.php.net/?id=27555&edit=1

[PHP-DOC] #27555 [Opn]: Unable to modify $_SESSION from __destruct()

[derick]

 ID:   27555
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jaanus at heeringson dot com
 Status:   Open
-Bug Type: Session related
+Bug Type: Documentation problem
 Operating System: Linux 2.4.24
 PHP Version:  5CVS-2004-03-10 (dev)
 New Comment:

Destructors are run (when not unset-ing yourself) after the session
module finalizes the session so everything done in constructors has no
effect. I agree it's not optimal behavior, but I don't think we need to
classify it as a bug. It is not documented though so I'm making this a
documentation problem.


Previous Comments:


[2004-03-11 02:35:15] jaanus at heeringson dot com

Yes, but that is not the issue here, is it? What this bug is about is
the unability to add session variables from __destruct(). Obviously you
have to reload the page to se the effect on the real session. The
[destructor] => Yes will NEVER appear in $_SESSION.



[2004-03-10 19:50:59] [EMAIL PROTECTED]

If you put something like "echo 'this happens now';" line in the
__destruct() call you will see that it's executed AFTER your print_r()
line. This is correct behaviour.





[2004-03-10 18:42:06] jaanus at heeringson dot com

Description:

Unable to add session variables from the __destruct() handler in a
class. The $_SESSION variable can be accessed and viewed in the
__destruct() handler though.

Reproduce code:
---






Expected result:

Array

(

[destructor] => Yes

[working] => Yes

)

Actual result:
--
Array

(

[working] => Yes

)





-- 
Edit this bug report at http://bugs.php.net/?id=27555&edit=1