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 12 11:49, Sebastian Huber wrote: > > ----- Freddie Chopin <freddie_chopin@op.pl> schrieb: > > On Fri, 2017-08-11 at 15:47 +0200, Corinna Vinschen wrote: > > > 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. > > > > +1 from me (; > > > > Regards, > > FCh > > Such a type change may break binary compatibility due to C++ name mangling. Very good point. If int32_t is defined as int, we get an i rather than an l in the mangled name of C++ methods/functions. The same goes for using int64_t vs. long and int64_t vs. long long which changes the l to an x. So we have to maintain the type "long" for backward compatibility an all systems which require backward compat. 64 bit Cygwin works with 'int64_t' since it's == long, but 32 bit Cygwin would be broken by using int32_t because it's defined as int. 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. 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] |