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


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]