This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH] Change time_t to 64-bit by default
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?
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada