Fwd: struct tm problem
Marco Atzeri
marco.atzeri@gmail.com
Thu Mar 6 18:15:00 GMT 2014
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
More information about the Cygwin
mailing list