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.


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]