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

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

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.

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