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:54, Derick Rethans wrote: > On Fri, 22 Aug 2014, Anatol Belski wrote: > > >> On Fri, August 22, 2014 14:01, Derick Rethans 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=e49e163a9ed7d4e38f9 >>>> ab7 24003c46c9f1ea2cb4 >>>> >>>> >>>> >>>> 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. >>> >>> >> 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? > > Yeah, those datatypes should already be there. What needs fixing to make > it work? > I think now that it's unavoidable to create an arch dependent portable type as timelib_sll is always 64 bit. Please take a look https://gist.github.com/weltling/e2c295a1c2efed62890e . The only difference here would be that it would always return timelib_sll even on 32 bit build (however within 32 bit range). If not that, it'd be probably ok. But IMHO not clean. Probably it would be better to pull the #ifdef's into the timelib.h header to define things like TIMELIB_SLL_MAX and so on, and also to define a portable type, then several places in timelib could be moved to portable types. I you don't mind, i'd rather go this way. Regards Anatol