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, 22 Aug 2014, Anatol Belski wrote: > On Fri, August 22, 2014 17:17, Derick Rethans wrote: > > On Fri, 22 Aug 2014, Anatol Belski wrote: > > > >> On Fri, August 22, 2014 14:54, Derick Rethans wrote: > >> > >>> 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. > > > > Right, but timelib_ssl is supposed to be that portable 64bit int > > type. > > > Exactly, it's 64 bit, that's why the patch in the gist would cause > compiler warning when timelib_date_to_int() used in 32 bit PHP. But we > need a type which would go with PHP types bitness, probably > timelib_int or alike. Or how would you see the solution, always 64 > bit? Yes, it should always go 64bit into PHP. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine