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 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 <[email protected]>         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