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] |
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. What you describe above is what we would have to do if we change sizeof(time_t) from 4 to 8 on 32 bit, which is something I won't have on my plate any time soon. I'm quite satisfied that the 64 bit version has a 8 byte time_t. Not that I wouldn't appreciate patches... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
pgpiNvwZUFfy4.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |