Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.5.5

Bug #5095 Code makes no sense
Submitted: 2005-08-15 04:04 UTC
From: rasmus Assigned: vincentlascaux
Status: Closed Package: File_Archive
PHP Version: Irrelevant OS: Any
Roadmaps: (Not assigned)    

 [2005-08-15 04:04 UTC] rasmus
Description: ------------ The getMTime() method in File_Archive/Archive/Writer/Zip.php makes absolutely no sense. $mtime = ($time !== null ? getdate($time) : getdate()); $mtime = getdate(mktime(0, 0, 0, 12, 32, 1997)); It's always December 32, 1997? And then some nasty regex ending in an eval()?


 [2005-08-15 18:04 UTC] vincentlascaux
This bug has been fixed in CVS. In case this was a documentation problem, the fix will show up at the end of next Sunday (CET) on In case this was a website problem, the change will show up on the website in short time. Thank you for the report, and for helping us make PEAR better. Looks like some debug code went into the production code. You can simply remove the line with the mktime(0, 0, 0, 12, 32, 1997); The regex ending in an eval is a valid code that makes perfect sense.
 [2005-08-15 20:06 UTC] rasmus
I really don't think using a preg_replace() and an eval() here is a good idea. pack() makes building binary strings like this trivial. This code is equivalent to the preg_replace();eval(); mess: $foo = dechex(($mtime['year']-1980<<25)| ($mtime['mon' ]<<21)| ($mtime['mday' ]<<16)| ($mtime['hours' ]<<11)| ($mtime['minutes']<<5)| ($mtime['seconds']>>1)); $mtime = pack("h*",strrev($foo)); it's also much faster. Whenever you find yourself using an eval() you need to stop and think a bit. There is almost always a better way.
 [2005-08-16 18:37 UTC] vincentlascaux
This is not a bug. I will considere using pack rather than the eval...