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 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? Regards Anatol