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 14 10:46, Sebastian Huber wrote: > > > ----- Am 14. Aug 2017 um 10:17 schrieb Corinna Vinschen vinschen@redhat.com: > [...] > > I don't know for other systems. But the point is, by changing to > > 64 bit time_t we break backward compat for all systems with 32 bit long > > anyway. However, the --enable-32bit_time_t option should use 'long' > > in the first place. > > What about --enable-long-time_t with enough words in the documentation > to explain this properly? > > Defines time_t to long. On platforms with a 32-bit long type this > gives raise to the year 2038 problem. This option is not the default. > The default type for time_t is a signed 64-bit integer. I was leaning towards enabling this option so that the type is always 32 bit. I.e., use long on 32 bit systems but, say, int32_t on 64 bit system. If that makes sense at all. If not, fine with me. In terms of the C++ ABI, we should really use the type "long" for 64 bit systems as well by default, if long is a 64 bit type. You never know if the int_XXX64_t types are not defined as 'long long' and then break the ABI again. 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] |