X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; q=dns; s=default; b=ea zmmsT2IHnw8MF24FU7lUErhf2SkVGmPZe9db49WOU3yfRLDU6L8AupsvLkK2NVvm CjQqiCQEObn0xd2B3hkS8PPkLNKqlYEGC4WmYlEkpzeDVGknY925geQW7br+aaTf EuArs5uawEyiOEswFRf5jy6HicND5/8BGJ4wMl5/4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; s=default; bh=W/8LURqc oE5rxc/cgMKE3nfHkH8=; b=xvwfu/c+JKOp6VjMa6iB4PFLmupRhUzkp621bDK3 0ogxudbtAxb5JDFW1ryjzA6V+lRdtZlRRbqW7liVU7mvuksMDXORqhXdjvDAPKb2 WX086Zt8KImMaD3OZ0hUkTXFYotFV1QZcHoAB9KKMJp35wx9rFrov6RX/6HekOJX xlM= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 X-HELO: mail-ob0-f179.google.com MIME-Version: 1.0 X-Received: by 10.182.107.232 with SMTP id hf8mr267809obb.75.1394108230442; Thu, 06 Mar 2014 04:17:10 -0800 (PST) In-Reply-To: References: <20140304081928 DOT GF7236 AT calimero DOT vinschen DOT de> <53172C18 DOT 5090906 AT redhat DOT com> <20140305140553 DOT GC2192 AT calimero DOT vinschen DOT de> Date: Thu, 6 Mar 2014 13:17:10 +0100 Message-ID: Subject: Fwd: struct tm problem From: Irfan Adilovic To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes 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. -- Irfan > 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 -- 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