Re: Introduction and 64 bit time_t

[Corinna Vinschen <vinschen at redhat dot com>]

On Aug  9 13:47, Philipp.Trommler@preh.de wrote:
> Am Mittwoch, den 09.08.2017, 14:35 +0200 schrieb Corinna Vinschen:
> 
> [snip]
> 
> > I'd prefer to use the type long on LP64 systems, but long long should
> > work fine for all 32 bit systems (baring 32 bit Cygwin).
> > 
> > However, a developer might want to design an embedded system still
> > using
> > a 32 bit time_t for the time being, so there should be some build-
> > time
> > switch for this case.  We're talking about a 21 year timeframe, which
> > may still be more than enough for some systems.
> 
> So we can agree on a build-time switch like --enable-long-long-time-t
> which defaults to off? That way the compilation of newlib itself could
> be handled easily, but for the compilation of applications using time_t
> I'm facing (at least) two possible implementations:
> 
> 1. Having the user define something before including time.h in order to
>    select the non-default long long, e.g.
> 
>       #define _USE_LONG_LONG_TIME_T
>       #include <time.h>
> 
> 2. Rewriting either time.h or sys/types.h at build-time depending on
>    the configure switch to define this value or, even simpler, rewrite
>    the definition of _TIME_T_ at build-time.
> 
> Am I correct here and which of these implementations would you prefer?
> Or am I missing something completely here?

newlib/newlib.hin


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature