Re: [PATCH] Change time_t to 64-bit by default

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

On 2017-09-07 15:36, Freddie Chopin wrote:
> On Thu, 2017-09-07 at 14:59 -0600, Brian Inglis wrote:
>> On 2017-09-07 12:47, Brian Inglis wrote:
>>> On 2017-09-07 10:03, Sebastian Huber wrote:
>>>>
>>>> ----- Freddie Chopin <freddie_chopin@op.pl> schrieb:
>>>>> On Thu, 2017-09-07 at 15:00 +0200, Sebastian Huber wrote:
>>>>>> The casts in Newlib gmtime_r() look pretty useless. I will
>>>>>> send a
>>>>>> patch 
>>>>>> with:
>>>>>>
>>>>>> diff --git a/newlib/libc/time/gmtime_r.c
>>>>>> b/newlib/libc/time/gmtime_r.c
>>>>>> index 81c7c94b1..6475df3ba 100644
>>>>>> --- a/newlib/libc/time/gmtime_r.c
>>>>>> +++ b/newlib/libc/time/gmtime_r.c
>>>>>> @@ -56,8 +56,8 @@ _DEFUN (gmtime_r, (tim_p, res),
>>>>>>     unsigned erayear, yearday, month, day;
>>>>>>     unsigned long eraday;
>>>>>>
>>>>>> -  days = ((long)lcltime) / SECSPERDAY +
>>>>>> EPOCH_ADJUSTMENT_DAYS;
>>>>>> -  rem = ((long)lcltime) % SECSPERDAY;
>>>>>> +  days = lcltime / SECSPERDAY + EPOCH_ADJUSTMENT_DAYS;
>>>>>> +  rem = lcltime % SECSPERDAY;
>>>>>>     if (rem < 0)
>>>>>>       {
>>>>>>         rem += SECSPERDAY;
>>>>>
>>>>> You should also replace "long days, rem;" with "time_t days,
>>>>> rem;".
>>>>
>>>> 2147483647 days are roughly 5879489 years. This should be enough
>>>> for most applications.
>>>
>>> The library supports tm_year from -2^31 -2147483648 to 2^31-1
>>> 2147483647 and
>>> year from -2^31+1900 -2147481748 to 2^31-1+1900 2147485547 allowing
>>> time_t from
>>> about -67768100536348801 to 67768036191676799.
>>
>> Should int ... year be changed to long year or time_t year to be able
>> to handle
>> tm_year + 1900 mentioned above?
> 
> Probably, but there's a high probability that there are more things
> that would need changing - for example without additional casts this:
> 
> year = ADJUSTED_EPOCH_YEAR + erayear + era * YEARS_PER_ERA + (month <= 1);
> 
> would probably be calculated as "int" anyway.

Those are the problems I'm looking to patch.
The question is, going forward, should we use long for bigger than int values as
usual, or use time_t instead, to consistently avoid long, in these time functions.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada