X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; q=dns; s=default; b=sT
	P/EYAz6fqywi7hggA81+BFIHUDOXm5lqtvWRg07lGRqmowBu80nGZIkaa0p3Ah+T
	sjiFozWLzuMmT1YLFe3rXpZepQ9cmyscftPj5Dg/KAFqkQM0qfbweThENS/WgDI7
	smm6FOdcwbilS0CiRtNQhwqQF/4MGBPXtmsJgtjdQ=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; s=default; bh=DHPEvXN7
	oFXUvaqv2Y8eIUWsQB4=; b=ZO6b8rgxjHy6JTaxrjrmpew1xqaoUaSaBzLUjlAP
	e6gYxIdUR2rERZ+cKpqjwQgJKlVpqcV4GzAS2jz/1Pr1cYGQLrBJm5DR1mJ/biw/
	ymAxD6qT0NvtY69P5tADzDe6drTASp61lniFMKib6s0mbQsiEJ/+XHjWc9M9GRP3
	UpI=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=0.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2
X-HELO:	mail-oa0-f48.google.com
MIME-Version:	1.0
X-Received:	by 10.60.83.140 with SMTP id q12mr4436090oey.10.1394016303770; Wed, 05 Mar 2014 02:45:03 -0800 (PST)
In-Reply-To:	<20140304081928.GF7236@calimero.vinschen.de>
References:	<CAJoYywWqyBYEJKriugeU0deHm=DsS_LYgHotaX6K=q6TO_tmQQ AT mail DOT gmail DOT com> <20140304081928 DOT GF7236 AT calimero DOT vinschen DOT de>
Date:	Wed, 5 Mar 2014 11:45:03 +0100
Message-ID:	<CAJoYywUF2gpX5+-9H3gExyRMYUtJQyi_mHOX42uG9kRfaQ0Nvg@mail.gmail.com>
Subject:	Re: struct tm problem
From:	Irfan Adilovic <irfanadilovic AT gmail DOT com>
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes

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

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/localtime.cc 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/localtime.cc 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

> http://cygwin.com/acronyms/#SHTDI
>
> 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:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -