struct tm problem

[Corinna Vinschen]

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>