This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Changes the default size of time_t to 64 bit.


On Aug 11 13:53, Philipp.Trommler@preh.de wrote:
> Am Freitag, den 11.08.2017, 15:47 +0200 schrieb Corinna Vinschen:
> > On Aug 11 15:40, Corinna Vinschen wrote:
> > > 
> > > On Aug 11 14:23, Freddie Chopin wrote:
> > > > 
> > > > On Fri, 2017-08-11 at 13:20 +0200, philipp.trommler@preh.de
> > > > wrote:
> > > > > 
> > > > > +`--enable-32bit-time_t'
> > > > > +     Use a time_t that is defined to long, regardless of the
> > > > > wordsize of
> > > > > +     the target. This may lead to problems in January 2038
> > > > > when the
> > > > > 32 bit
> > > > > +     timestamp overflows but on the other hand may yield
> > > > > better
> > > > > +     performance than 64 bit timestamps.
> > > > > +     Disabled by default.
> > > > I would say that the option is misleading, as "long" may as well
> > > > have
> > > > 64-bits on 64-bit systems. Maybe it would be better to have it as
> > > > "
> > > > --disable-64bit-time_t"? This would have a similar issue, but be
> > > > actually  more consistent with the logic of the patch - time_t is
> > > > either 64-bit or whatever "long" is.
> > > what about something like --enable-time_t-is-long-only ?
> > Alternatively, what about sticking to --enable-32bit-time_t and mean
> > it?
> > 
> > We could define time_t as __int32_t or __int_least32_t then, rather
> > than using long.  The definition of time_t is then actually
> > controlled
> > by a concious decision of the developer.
> 
> While I like the idea of a concious decision, the benefit of something
> like --enable-time_t-is-long-only and defining it to long is that
> keeping compatibility is a no-brainer for the users. They get exactly
> what they were used to, including the changes from long to time_t in
> the whole time code.

I think "no-brainer" is not the right word here.  The developer of a 32
bit system will now always get 64 bit time_t, unless she explicitely
uses --enable-something-with-time_t.  Since there's a decision to make
anyway, we can just as well make sure that the developer gets exactly
what she's asking for.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]