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 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:
>> >
>> >
>> > 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? Surely that can't be done in the cygwin1.dll, it must be
the dynamic linker, or something between my executable and

If it is recognized that the executable was compiled against a
different sized struct tm, how would you instruct cygwin1.dll code not
to write to tm_gmtoff? I'm imagining a global variable _have_gmtoff
which the timesub function in cygwin/ checks, but what if
the executable loads another dll which was compiled against the
correct struct tm? Now I'm imagining rewriting call sites at load time
to call the correct cygwin/ function depending on how the
call site was compiled... But this seems waaay to hard-core.

I'm just curious at this point, because I don't see any way of fixing
this, and you seem to assume it's just something that needs to be done
-- am I missing something obvious? Where would one start? Do you at
least have an outline of how one would fix this?

-- Irfan

> I'll put this on my TODO list, but if somebody want's to take a stab
> at it, feel free.
> Corinna
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Maintainer                 cygwin AT cygwin DOT com
> Red Hat

Problem reports:
Unsubscribe info:

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