#23298 [Bgs->Opn]: Floating point data loss in serialize() (and sessions)

ID: 23298 User updated by: swbrown at ucsd dot edu Reported By: swbrown at ucsd dot edu -Status: Bogus +Status: Open Bug Type: Variables related Operating System: any PHP Version: 4.3.1 New Comment: The test is not bogus, and is not incorrect. The test proves the serialize()/unserialize() pair is a lossy operation for some floats (but not 'short' ones like 1.0/2.0, which points to a truncation issue in reading or writing), which should be considered a bug. The bug is also not fixed in CVS. I just tested 5.0.x and 4.3.x nightly snapshots and both failed. Please examine the test case again. When this bug is fixed, it will print SUCCESS. Currently, it will print FAIL, as the output of unserialize(serialize(..)) isn't the input for non-trivial floats. Previous Comments: ------------------------------------------------------------------------ [2003-04-23 02:59:30] sniper@php.net Your test is bogus. It should print 'SUCCESS' where it now says 'FAIL'. (using latest stable cvs version of PHP, both $x and $var are exactly the same, thus there is no kind of truncation) ------------------------------------------------------------------------ [2003-04-21 15:22:45] swbrown at ucsd dot edu I ran into a bug in my code where the floating point number I put in a session variable changed slightly when it was loaded from the session the next time around, which in this case caused some math to differ by 1 depending on if the object had been through a session before. This was definately not expected behavior, as I would expect data to be invariant under serialization. I poked around at this for a bit, and I'm guessing that PHP uses serialize() to serialize session variables, and serialize() has data loss issues with float/double as it tries to convert them into truncated base 10 numbers. Test case: <?php $var = 1.0 / 7.0; $x = unserialize(serialize($var)); if($x != $var) print("FAIL\n"); else print("SUCCESS\n"); ?> One way I think this could be fixed is to add a new serialize field type other than 'd' for serialize()ing floats/doubles so that future PHP releases can serialize the entire float in base 16 or something so it won't alter data and won't break BC. Maybe 'e' for IEEE or something. Serialization should never alter the data being serialized, or it creates all sorts of funky problems (like mine where the object acts slightly different depending on if it's gone through a session). ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=23298&edit=1