Req #36424 [Com]: Keeping reference info through recursive calls to serialize()
Edit report at http://bugs.php.net/bug.php?id=36424&edit=1
ID: 36424
Comment by: peter at desk dot nl
Reported by:mastabog at hotmail dot com
Summary:Keeping reference info through recursive calls to
serialize()
Status: Assigned
Type: Feature/Change Request
Package:Unknown/Other Function
Operating System: *
PHP Version:5.2.14-dev
Assigned To:mike
Block user comment: N
Private report: N
New Comment:
I've just been bitten by this bug (in php 5.3.3), cost me half a day to
figure it out... it's highly annoying because I can't go back to using
__sleep and __wakeup without much rewriting, and while working around it
is feasible, it's pretty hacky in my situation.
what has happened to the patch mentioned in may ? was it ever committed
?
Previous Comments:
[2010-05-26 09:24:41] m...@php.net
Automatic comment from SVN on behalf of mike
Revision: http://svn.php.net/viewvc/?view=revision&revision=299770
Log: Added support for object references in recursive serialize() calls.
FR #36424
[2010-05-21 13:08:07] mastabog at hotmail dot com
I still don't understand why this is not seen as a bug. My example shows
that without "implements Serializable" object references are honoured
(as expected) while with "implements Serializable" object references are
broken (which is unexpected).
Seeing you classified this as "feature request" makes me think that
breaking object references was actually intended behaviour or that there
is a way to maintain object references when implementing Serializable.
Can you then please provide the body of the serialize() and
unserialize() methods in class A in the example below that will maintain
object references as expected, i.e. $new_oC->A === $new_oC->B->A?
class A implements Serializable
{
public function serialize ()
{
[...]
}
function unserialize($serialized)
{
[...]
}
}
class B extends A
{
public $A;
}
class C extends A
{
public $A;
public $B;
}
$oC = new C();
$oC->A = new A();
$oC->B = new B();
$oC->B->A = $oC->A;
echo $oC->A === $oC->B->A ? "yes" : "no", "\n";
$ser = serialize($oC);
$new_oC = unserialize($ser);
echo $new_oC->A === $new_oC->B->A ? "yes" : "no", "\n";
[2010-05-21 11:19:54] m...@php.net
Reclassified as Change Request.
JFYI: http://news.php.net/php.internals/48369
[2010-05-20 23:21:02] mastabog at hotmail dot com
Why has the status of this been changed to "bogus"?
Are we to understand that the devs regard this as being intended
behaviour, i.e. the Serializable interface breaks object references of
objects implementing it?
The initial reproduce code shows that what was an object reference
before is no longer a reference after unserialization ... this is a bug.
There may be other (better) reproduce codes but the bug is still there.
Why not try and fix it?
Well, I tried but I think I will give up ... it's been 4+ years!
[2010-05-20 18:31:13] mastabog at hotmail dot com
If you remove "implements Serializable" then it works as expected and
the reproduce code shows that. Revealing the bug was what my report was
about.
It's a bug. It surprises me that nobody wants to fix it after more than
4 years ... apparently it's just me that considers this bug to be
important which is why I still avoid using the Serializable interface
altogether. It's unreliable.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=36424
--
Edit this bug report at http://bugs.php.net/bug.php?id=36424&edit=1
#29119 [Opn]: html_entity_decode misbehaves with UTF-8
ID: 29119
User updated by: peter at desk dot nl
Reported By: peter at desk dot nl
Status: Open
Bug Type: Strings related
Operating System: Linux 2.6.5
PHP Version: 5.0.0RC3
New Comment:
nb : the above-mentioned online tests at http://fire.desk.nl/ are now
no longer relevant as that machine runs the patched version.
Previous Comments:
[2004-07-19 14:26:57] peter at desk dot nl
after looking at the sources, this patch seems to fix it :
fire:/home/peter/php-5.0.0/ext/standard# diff -u html.c.org html.c
--- html.c.org 2004-07-19 14:24:08.0 +0200
+++ html.c 2004-07-19 14:13:50.0 +0200
@@ -158,7 +158,7 @@
"thinsp", NULL, NULL, "zwnj", "zwj", "lrm", "rlm",
NULL, NULL, NULL, "ndash", "mdash", NULL, NULL, NULL,
"lsquo", "rsquo", "sbquo", NULL, "ldquo", "rdquo", "bdquo",
- "dagger", "Dagger", "bull", NULL, NULL, NULL, "hellip",
+ NULL,"dagger", "Dagger","bull", NULL, NULL, NULL,
"hellip",
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, "permil",
NULL,
"prime", "Prime", NULL, NULL, NULL, NULL, NULL, "lsaquo",
"rsaquo",
NULL, NULL, NULL, "oline", NULL, NULL, NULL, NULL, NULL,
[2004-07-13 16:53:49] peter at desk dot nl
Description:
when decoding named entities with html_entity_decode, the resulting
characters are sometimes incorrect. e.g., "€" becomes the UTF-8
representation of the ⁄ entity (fraction slash). not all entities
are incorrectly translated, though. numerical entities work correctly.
tested with both php-5.0.0RC3 and the proposed -RC4 from
snaps.php.net/~andi/
config :
./configure --with-apxs=/usr/bin/apxs --with-mysql=/usr/local/mysql
--with-gd --enable-safe-mode --with-dom=/usr --enable-ftp --with-zlib
--with-xsl --with-xmlrpc --enable-cli --enable-bcmath --with-iconv
--with-jpeg-dir=/usr --with-png-dir=/usr --with-xpm-dir=/usr/X11R6
Reproduce code:
---
// all tests are viewed with browser encoding forced on UTF-8.
";
print
htmlentities(html_entity_decode("€",ENT_NOQUOTES,"UTF-8"),ENT_NOQUOTES,"UTF-8");
?>
// other test also available on
// http://fire.desk.nl/decode/index.php
// (just enter € and submit)
// and http://fire.desk.nl/decode/index.phps (source)
Expected result:
a euro-sign
a euro-sign
Actual result:
--
a fractional slash
a euro-sign
--
Edit this bug report at http://bugs.php.net/?id=29119&edit=1
#29119 [Opn]: html_entity_decode misbehaves with UTF-8
ID: 29119
User updated by: peter at desk dot nl
Reported By: peter at desk dot nl
Status: Open
Bug Type: Strings related
Operating System: Linux 2.6.5
PHP Version: 5.0.0RC3
New Comment:
after looking at the sources, this patch seems to fix it :
fire:/home/peter/php-5.0.0/ext/standard# diff -u html.c.org html.c
--- html.c.org 2004-07-19 14:24:08.0 +0200
+++ html.c 2004-07-19 14:13:50.0 +0200
@@ -158,7 +158,7 @@
"thinsp", NULL, NULL, "zwnj", "zwj", "lrm", "rlm",
NULL, NULL, NULL, "ndash", "mdash", NULL, NULL, NULL,
"lsquo", "rsquo", "sbquo", NULL, "ldquo", "rdquo", "bdquo",
- "dagger", "Dagger", "bull", NULL, NULL, NULL, "hellip",
+ NULL,"dagger", "Dagger","bull", NULL, NULL, NULL,
"hellip",
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, "permil",
NULL,
"prime", "Prime", NULL, NULL, NULL, NULL, NULL, "lsaquo",
"rsaquo",
NULL, NULL, NULL, "oline", NULL, NULL, NULL, NULL, NULL,
Previous Comments:
[2004-07-13 16:53:49] peter at desk dot nl
Description:
when decoding named entities with html_entity_decode, the resulting
characters are sometimes incorrect. e.g., "€" becomes the UTF-8
representation of the ⁄ entity (fraction slash). not all entities
are incorrectly translated, though. numerical entities work correctly.
tested with both php-5.0.0RC3 and the proposed -RC4 from
snaps.php.net/~andi/
config :
./configure --with-apxs=/usr/bin/apxs --with-mysql=/usr/local/mysql
--with-gd --enable-safe-mode --with-dom=/usr --enable-ftp --with-zlib
--with-xsl --with-xmlrpc --enable-cli --enable-bcmath --with-iconv
--with-jpeg-dir=/usr --with-png-dir=/usr --with-xpm-dir=/usr/X11R6
Reproduce code:
---
// all tests are viewed with browser encoding forced on UTF-8.
";
print
htmlentities(html_entity_decode("€",ENT_NOQUOTES,"UTF-8"),ENT_NOQUOTES,"UTF-8");
?>
// other test also available on
// http://fire.desk.nl/decode/index.php
// (just enter € and submit)
// and http://fire.desk.nl/decode/index.phps (source)
Expected result:
a euro-sign
a euro-sign
Actual result:
--
a fractional slash
a euro-sign
--
Edit this bug report at http://bugs.php.net/?id=29119&edit=1
#29119 [NEW]: html_entity_decode misbehaves with UTF-8
From: peter at desk dot nl
Operating system: Linux 2.6.5
PHP version: 5.0.0RC3
PHP Bug Type: Strings related
Bug description: html_entity_decode misbehaves with UTF-8
Description:
when decoding named entities with html_entity_decode, the resulting
characters are sometimes incorrect. e.g., "€" becomes the UTF-8
representation of the ⁄ entity (fraction slash). not all entities
are incorrectly translated, though. numerical entities work correctly.
tested with both php-5.0.0RC3 and the proposed -RC4 from
snaps.php.net/~andi/
config :
./configure --with-apxs=/usr/bin/apxs --with-mysql=/usr/local/mysql
--with-gd --enable-safe-mode --with-dom=/usr --enable-ftp --with-zlib
--with-xsl --with-xmlrpc --enable-cli --enable-bcmath --with-iconv
--with-jpeg-dir=/usr --with-png-dir=/usr --with-xpm-dir=/usr/X11R6
Reproduce code:
---
// all tests are viewed with browser encoding forced on UTF-8.
";
print
htmlentities(html_entity_decode("€",ENT_NOQUOTES,"UTF-8"),ENT_NOQUOTES,"UTF-8");
?>
// other test also available on
// http://fire.desk.nl/decode/index.php
// (just enter € and submit)
// and http://fire.desk.nl/decode/index.phps (source)
Expected result:
a euro-sign
a euro-sign
Actual result:
--
a fractional slash
a euro-sign
--
Edit bug report at http://bugs.php.net/?id=29119&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29119&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29119&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29119&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29119&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29119&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29119&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29119&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29119&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29119&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29119&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29119&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29119&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29119&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29119&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29119&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29119&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29119&r=float
