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: Fwd: struct tm problem




On 06/03/2014 13:17, Irfan Adilovic wrote:
On Wed, Mar 5, 2014 at 3:05 PM, Corinna Vinschen wrote:
On Mar  5 06:52, Eric Blake wrote:
On 03/05/2014 03:45 AM, Irfan Adilovic wrote:
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?

Linker magic, the same as how we converted to 64-bit stat, and the same
as what we will eventually have to do if we want to convert to 64-bit
time_t.  Basically, we add a new entry point, and alias the public name
to the new entry point.  Any old program is still linked to the old
name, where we know they use the smaller size.  Any new program is
linked to the new name, where we know they use the larger size.  New
programs cannot run against the old dll, but the new dll is able to
handle both old and new apps by virtue of dual entry points.

Not in this case.  I just applied a patch which simply tests the API
version of the executable and skips the code handling tm_offset and
tm_zone, which are just a few lines anyway.

Can you point me to the patch in CVS? I'd like to see the code --
being curious, as I already said.


http://cygwin.com/ml/cygwin-cvs/2014-q1/msg00092.html

--
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


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