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
pgp2xGcHlSwZr.pgp
Description: PGP signature
