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, 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