This is the mail archive of the cygwin mailing list for the Cygwin 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: struct tm problem


On Mar  5 11:45, Irfan Adilovic wrote:
> On Tue, Mar 4, 2014 at 9:19 AM, Corinna Vinschen wrote:
> > On Mar  3 23:28, Irfan Adilovic wrote:
> >> (Please note the date of the quoted emails)
> >>
> >> On Mon, May 23, 2005 at 07:58:01PM -0700, Yitzchak Scott-Thoennes wrote:
> >> > On Mon, May 23, 2005 at 06:34:21PM +0430, Alireza Ghasemi wrote:
> >> > > Hello,
> >> > > I have downloaded some c++ libraries and tried to download them.But All of
> >> > > them give an error like :
> >> > > "'struct tm' has no member called 'tm_gmtoff'"
> >> > > (tm is defined as 'time_t t; time(&t);tm* ptm = localtime(&t);')
> >> > > I guess that tm should be defined in ctime header.
> >> > > What's the problem and what should I do?
> >> > > Thanks
> >> >
> >> > tm_gmtoff is not required by the standard:
> >> > http://www.opengroup.org/onlinepubs/009695399/basedefs/time.h.html
> >> >
> >> > However, it is an extension available in the Olson tzcode, which
> >> > cygwin seems to use.  Enabling it would seem to be a matter of
> >> > setting -DTM_GMTOFF=tm_gmtoff and adding it to time.h.
> >
> > And same for TM_ZONE.
> >
> >> I have successfully done this and use the tm_gmtoff in my code
> >> actively. Is there a reason this isn't enabled? Is there any interest
> >> in the community to make tm_gmtoff available by default (It's so easy,
> >> it's a shame it's not :-))?
> >
> > It's easy to change the struct, but changing the size of a structure
> > is an incompatible change to existing applications which leads to
> > overwriting memory.
> >
> > A change to Cygwin involves an extra check if the application has been
> > build against an older or a newer version of Cygwin, and to fill the
> > tm_gmtoff/tm_zone structure members dependent on that.  So it's not just
> > done by defining TM_GMTOFF and TM_ZONE.
> 
> Now that you mention the incompatibility, it seems logical -- the size
> of the struct is hard-coded when allocation frames in the executable
> (or when mallocing), and passing that to the library will write
> tm_gmtoff past the allocated area -- but how can one even try to
> recognize and act upon that at runtime, without recompiling the
> executable?

The Cygwin DLL can check under which version of the Cygwin DLL an
executable has been compiled.  We're using this knowledge already in
other circumstances.  If the DLL finds it has been compiled under an old
Cygwin version which doesn't know these new members, it will not try to
read or write these members, if it's an executabled compiled under a
newer DLL which knows these members, it will utilize them.  If you're
running a new executable under an old version of the DLL, the members
will probably contain garbage, but that's an unsupported scenario
anyway.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpKK6r3ovh_7.pgp
Description: PGP signature


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