struct tm problem
Corinna Vinschen
corinna-cygwin@cygwin.com
Wed Mar 5 16:05:00 GMT 2014
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20140305/2738b525/attachment.sig>
More information about the Cygwin
mailing list