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