[PATCH] Change time_t to 64-bit by default

Brian Inglis Brian.Inglis@SystematicSw.ab.ca
Fri Sep 8 15:00:00 GMT 2017


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,
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.

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.

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.

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



More information about the Newlib mailing list