From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: windows build failure Date: Sat, 12 Oct 2013 08:55:14 -0700 Organization: UCLA Computer Science Department Message-ID: <525970E2.6050401@cs.ucla.edu> References: <83wqmeocl5.fsf@gnu.org> <83ioxynvpb.fsf@gnu.org> <87zjrae0q7.fsf@gmail.com> <83eh8mnu8h.fsf@gnu.org> <87ob7qdzxj.fsf@gmail.com> <83a9janq2l.fsf@gnu.org> <87bo3oew5i.fsf@gmail.com> <83wqmclwja.fsf@gnu.org> <8761twemxb.fsf@gmail.com> <83txhglke0.fsf@gnu.org> <871u4keezm.fsf@gmail.com> <83pps4kl3s.fsf@gnu.org> <87vc1v4lld.fsf@gmail.com> <834n9fle10.fsf@gnu.org> <87k3ib4fl7.fsf@gmail.com> <8338ozl7cd.fsf@gnu.org> <83bo2ur4yq.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1381593345 9090 80.91.229.3 (12 Oct 2013 15:55:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Oct 2013 15:55:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 12 17:55:48 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VV1Xf-0000Xc-Rs for ged-emacs-devel@m.gmane.org; Sat, 12 Oct 2013 17:55:47 +0200 Original-Received: from localhost ([::1]:58602 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VV1Xf-0006cm-J3 for ged-emacs-devel@m.gmane.org; Sat, 12 Oct 2013 11:55:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VV1XW-0006cY-C4 for emacs-devel@gnu.org; Sat, 12 Oct 2013 11:55:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VV1XO-0002Mk-Od for emacs-devel@gnu.org; Sat, 12 Oct 2013 11:55:38 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:52745) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VV1XF-0002LQ-4x; Sat, 12 Oct 2013 11:55:21 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 2E4A3A60005; Sat, 12 Oct 2013 08:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yD8U5fGeV8l; Sat, 12 Oct 2013 08:55:19 -0700 (PDT) Original-Received: from [192.168.1.9] (pool-108-0-233-62.lsanca.fios.verizon.net [108.0.233.62]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id B503339E80F8; Sat, 12 Oct 2013 08:55:19 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 In-Reply-To: <83bo2ur4yq.fsf@gnu.org> X-Enigmail-Version: 1.5.2 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:164149 Archived-At: Eli Zaretskii wrote: > This is because MinGW32 runtime 4.0 also moved > to using a 64-bit time_t type by default, which according to my > testing screws up Emacs What screwups do you observe? Are they limited to MinGW32 or might they affect POSIXish 32-bit hosts with 64-bit time_t? The reason I'm asking is that on on 32-bit hosts, Emacs's hacky representation of time values is limited to time_t values in the range [- 2**45, 2**45), and Emacs reports an error via time_overflow when asked to compute a time out of that range, even if it is operating on a platform with 64-bit time_t values. So, if you set your system clock to 1116918-05-14 19:20:32 UTC on such a host, or otherwise deal with outlandish time stamps, Emacs will have screwups, and it won't be trivial to fix this.