Re: Re: com php-src: fixes to date: ext/date/lib/timelib.c ext/date/lib/timelib.h ext/date/php_date.c ext/date/php_date.h

On Fri, August 22, 2014 14:15, Pierre Joye wrote: > On Fri, Aug 22, 2014 at 2:01 PM, Derick Rethans <derick@php.net> wrote: > >> On Mon, 18 Aug 2014, Anatol Belski wrote: >> >> >>> Commit: e49e163a9ed7d4e38f9ab724003c46c9f1ea2cb4 >>> Author: Anatol Belski <ab@php.net> Mon, 18 Aug 2014 >>> 18:57:55 +0200 >>> Parents: b8324e6d635450562ecb253af38f22105e19e460 >>> Branches: master >>> >>> >>> Link: >>> >>> http://git.php.net/?p=php-src.git;a=commitdiff;h=e49e163a9ed7d4e38f9a >>> b724003c46c9f1ea2cb4 >>> >>> Log: >>> fixes to date >>> >>> Changed paths: >>> M ext/date/lib/timelib.c >>> M ext/date/lib/timelib.h >>> >> >> You can't just change timelib and introduce PHP specific constructs. It >> should be compilable outside of PHP as well. > > Then the right type must be used accordingly to the current > architecture. long is just meaningless and should be avoided. > > While I understand that this part of the core, always enabled and > widely used extension could be used outside PHP, it should be clean and > uses portable types. > I see, so I could suggest to introduce similar portable datatype inside of the timelib. Or, what i see there - the defs for timelib_ull and timelib_ll, with a little tweak they would be usable too. What would suffice? Regards Anatol