Re: [PHP-DEV] Re: [PHP-CVS] 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