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

[Corinna Vinschen <vinschen at redhat dot com>]

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.

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

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


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature