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.


Hi,

sorry for the late response, I've been quite busy the last days.

Do we have reached any consensus on the logic to use for the configure
parameter (enable-32bit vs. disable-64bit) and the type to use for
time_t (long on 64bit, long long on 32bit vs. fixed width types)?

I'll be unavailable the next two weeks but I'd like to adopt my patch
to that consensus afterwards.

Regards
Philipp


Am Montag, den 14.08.2017, 13:14 +0200 schrieb Freddie Chopin:
> On Mon, 2017-08-14 at 11:47 +0200, Sebastian Huber wrote:
> > 
> > ----- Am 14. Aug 2017 um 11:04 schrieb Freddie Chopin
> > freddie_chopin@
> > op.pl:
> > 
> > > 
> > > On Mon, 2017-08-14 at 10:46 +0200, Sebastian Huber wrote:
> > > > 
> > > > What about --enable-long-time_t with enough words in the
> > > > documentation to explain this properly?
> > > Maybe "--disable-long-long-time_t" would be more intuitive?
> > Why should be time_t of type long long on an LP64 target?
> The whole discussion is not about LP64 target, but about making
> time_t
> 64-bit on 32-bit platforms. For them, time_t should be set to "long
> long" or "int64_t" to achieve that goal.
> 
> The problem I see with "--enable-long-time_t" is that for me it seems
> that opposite option has "short" instead of "long", while in this
> case
> it will be "long long".
> 
> Regards,
> FCh
> 
> 

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