php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #50930 wrong date by php_date.c patch with ancient gcc/glibc versions
Submitted: 2010-02-03 21:17 UTC Modified: 2010-02-10 16:24 UTC
From: nathan dot kessler at hushmail dot me Assigned: derick (profile)
Status: Closed Package: Date/time related
PHP Version: 5.*, 6 OS: SuSE 7.3 i386 / gcc version 2.95
Private report: No CVE-ID: None
View Developer Edit
 [2010-02-03 21:17 UTC] nathan dot kessler at hushmail dot me 
Description:
------------
Right after updating 5.2.11 to 5.2.12 all phpscripts using date(function showed wrong years:

   2008 is 8624294332376
   2009 is 8628589299673
   2010 is 8632884266970
   2011 is 8637179234267
   2012 is 8641474201564

I reviewed patches of 5.2.12 and identified patch #50266 / revision 291371. If I compile without revision 291371 all years are fine. I see no definition of llabs in my systems /usr/include/stdlib.h like described in #50266. Perhaps this function is defined only under solaris?


Reproduce code:
---------------
<?php echo date( 'Y' ); ?>

Expected result:
----------------
2010

Actual result:
--------------
8632884266970

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-02-03 21:53 UTC] jani@php.net 
This is same thing as reported in bug #50899 and since this is much better report, closing that one in favor of this. 

llabs() is C99, so I guess that ancient GCC does not support it. I'd suggest upgrading the compiler as first thing you do. Many other things will break in future PHP versions as well if you stick with that. :)

I'll look into this, but since I don't have such old compiler around, this might take a while.
 [2010-02-03 21:57 UTC] jani@php.net 
Some links to help out a bit:

  http://svn.php.net/viewvc/?view=revision&revision=291371
 [2010-02-03 22:27 UTC] jani@php.net 
What exactly is HAVE_LLABS defined in your main/php_config.h file? (in the build)
 [2010-02-03 22:47 UTC] nathan dot kessler at hushmail dot me 
It's defined with 1:

/* Define if you have the llabs function.  */
#define HAVE_LLABS 1
 [2010-02-03 23:26 UTC] jani@php.net 
I'm considering reverting the patch for fixing bug #50266 since that was only a warning anyway..need to investigate a bit more though.
 [2010-02-03 23:28 UTC] jani@php.net 
Oops, that bug was no warning but an error. So can't really just revert..
 [2010-02-04 02:33 UTC] kmcgrail at apache dot org 
In my previous comment, I referred to the wrong patch.  I meant to say remove 291371.  The cookie warning from 286508 is good and valid IMO.

OK, so I believe the patch in 291371 definitely is causing the issue in combination with older GCC's.  Here's the testing I've done:

PHP 5.2.12 compiled by gcc 3.2.3 - SquirrelMail 1.2.19 works as well as PHPMyAdmin 2.11.10.

PHP 5.2.12 compiled by gcc 2.9.6 - SM 1.2.19 is broken with the error "You must be logged in to access this page."
PHPMyAdmin sporadically triggers "Warning: Expiry date cannot have a year greater then 9999"

Finally, PHP 5.2.12 compiled with revision 291371 removed with GCC 2.96 - PHPMyadmin & SquirrelMail works.

So I think the issue is with the llabs call as you expected and my experience confirms it.  If you have a patch you want me to test, let me know.
 [2010-02-04 18:57 UTC] jani@php.net 
I'll leave it for Derick to decide what to do. I suggest removing the whole check from config.m4 and replacing the llabs() stuff with some own macro/function used always for any and all compilers and systems.
 [2010-02-10 16:23 UTC] svn@php.net 
Automatic comment from SVN on behalf of derick
Revision: http://svn.php.net/viewvc/?view=revision&revision=294854
Log: - Added a test case for bug #45866
- Fixed tests: oo_002, bug46268
- Fixed bug #50930 (Wrong date by php_date.c patch with ancient gcc/glibc
  versions).
- Make sure faulty strings passed to DateTime::modify() notify the user.
- Revert fix for bug #50392 as it was fixed wrongly without a proper test case.
- Fixed a bug with the 'r' formatting function as the default buffer size that
  was allocated only fit 4 digit years.
 [2010-02-10 16:24 UTC] derick@php.net 
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Fixed in rev. 294854 by always relying on our own function.
 [2010-02-11 11:11 UTC] svn@php.net 
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=294880
Log: - merge fix for: #45866,#50930, revert fix for #50392, Fixed a bug with the 'r' formatting function, added or fixed tests for #45866 and #46268
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Dec 03 17:01:29 2024 UTC