Re: windows build failure

[Eli Zaretskii]

> Date: Sat, 12 Oct 2013 08:55:14 -0700
> From: Paul Eggert <address@hidden>
> CC: address@hidden
> 
> 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?

Functions that expect 32-bit time_t values and pointers to such values
get 64-bit values/pointers instead.

> Are they limited to MinGW32
> or might they affect POSIXish 32-bit hosts with 64-bit time_t?

The former, of course.  The problem is that MinGW developers tried to
find a way to adapt to the fact that the default system libc switched
to 64-bit time_t since Windows 7, but got confused between
compile-time decisions and run-time decisions.  So building Emacs on
Windows 7 and running it there might still work, but if the binary
gets installed on XP, there will be problems.

The only workaround I found was to force 32-bit time_t (which is what
previous MinGW runtime was using anyway).  MinGW developers promised
to fix that in the next release, but I will believe that when I see
it.

> 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.

So you are saying that 32-bit hosts will be dead for Emacs in about
half a year (if I interpret that time stamp correctly), is that right?