Re: Time Fixes Diff (was: Change time_t to 64-bit by default)

[Brian Inglis <Brian dot Inglis at SystematicSw dot ab dot ca>]

On 2017-09-08 10:34, Brian Inglis wrote:
> On 2017-09-08 09:00, Corinna Vinschen wrote:
>> On Sep  8 08:46, Brian Inglis wrote:
>>> On 2017-09-08 02:18, Corinna Vinschen wrote:
>>>> On Sep  8 07:40, Freddie Chopin wrote:
>>>>> On Thu, 2017-09-07 at 15:58 -0600, Brian Inglis wrote:
>>>>>> 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.
>>>>>
>>>>> I think we should go with time_t, which will be 32-bit or 64-bit long, 
>>>>> depending on what was chosen during newlib compilation.
>>>>
>>>> While that's nice and all, two points to keep in mind:
>>>>
>>>> * 64 bit computations are costly on 32 bit (or even 16 bit) platforms and
>>>>   should be avoided if overkill isn't your goal.
>>>>
>>>> * days, months, years, etc, are *all* of type int in struct tm, per
>>>>   POSIX. Adding 64 bit ops just to fold stuff back into ints might only 
>>>>   make marginal sense.
>>>
>>> Max year == MAX_INT + 1900 == 2^31-1 + 1900 == 2147485547 on 32 bit platforms,
>>
>> You wrote this before but it sounds like a pretty academic problem.
> 
> Check out the strftime.c regression test vectors before you conclude that.
> 
>>> if you want to avoid arbitrary limitations, and be as (Linux) compatible as
>>> possible, which the existing library tries to do, but there are various issues
>>> to be fixed. There are places where int, unsigned, long, and unsigned long are
>>> used which may or may not work depending on time_t, int, and long sizes.
>>
>> Glibc compat is nice, and as far as Cygwin is concerned I'm not
>> concerned for size.  However, newlib strives to small footprints
>> given that many embedded targets are using it.  This should be kept
>> in mind.
>>
>>>
>>> Is long bigger than int on all newlib platforms? What is bigger than int?
>>>
>>> Using time_t as required makes temps and variables big enough to avoid overflow
>>> for seconds, days, and years counts, without penalizing 32 bit time_t platforms.
>>
>> Rather than int, long, long long you can use explicit sized ints
>> like int16_t, int32_t, uint64_t.
> 
> We need space for things that are bigger than ints up to a few to a couple
> orders of magnitude smaller than time_t, not even half the length, so picking
> types smaller than time_t does not seem to be worth the code?
> 
>>> For I/O conversion of 64 bit time_t max year on 32 bit platforms long long is
>>> required, it may also be used with 32 bit time_t to avoid conditionals, and it
>>> imposes no extra overhead on 64 bit platforms.
>>>
>>> Everything depends on how many conditionals we want to use to minimize the data
>>> and code space and time spent at runtime and for development.
> 
> I'm inclined to use common code and types that will work correctly on all
> platforms *in places where they are needed* to get things working correctly,
> then we can worry about space and time reductions if required?
> 
> I can post diffs for discussion before making any local commits or patches.

Attached for discussion.

Used local.h definitions, removed some local duplications, changed
tests/compares of > ... - 1) to >= ..., changed declarations to time_t and added
casts for large secs, days, years counts to avoid overflow with extreme values,
cast to long long for I/O mainly snprintf.

Not yet tested due to unrelated build issues on other files in latest git pull.

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

Attachment: fix_time.diff
Description: Text document