[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#33847: 27.0.50; emacsclient does not find server socket

From: Paul Eggert
Subject: bug#33847: 27.0.50; emacsclient does not find server socket
Date: Sun, 25 Jul 2021 09:22:06 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

On 7/24/21 11:32 PM, Eli Zaretskii wrote:

No modules are affected by the --disable-year2038 option on MS-Windows.

It turns out that I was wrong about that. (I don't normally look at the MS-Windows part of Gnulib and misunderstood some of the code I was reading.) Please see gnulib/m4/year2038.m4 for details. This file is in the patches I sent, or you can see it directly here:


This code knows about MS-Windows, Mingw, _USE_32BIT_TIME_T, __MINGW_USE_VC2005_COMPAT, and so forth, and attempts to do the right thing. As near as I can make out it should work for the scenario you describe, but I don't use MS-Windows so I could well be wrong. If I'm wrong and this code doesn't do what you want, I suggest contacting bug-gnulib to alert Bruno Haible, who wrote that part of the code. I'll cc bug-gnulib so that Bruno sees this email. (Bruno, this discussion is at <https://bugs.gnu.org/33847#161>.)

Here's some more background. There are two Gnulib modules involved.

The largefile module ensures that a program can open/stat/etc. all files, by widening types like off_t, dev_t and time_t if necessary. If it finds that time_t is narrower than what the system can support, it attempts to widen time_t; if this attempt fails it issues a warning but continues.

The year2038 module is stricter: it insists that time_t be at least 64 bits and aborts 'configure' otherwise. (Strictly speaking, it should insist only on at least 33 bits (or 32 bits unsigned); I suppose I should look into fixing that.)

The Emacs patches that I sent do not use the year2038 module, because I expected that you wouldn't want to worry about the year 2038. The year2038 module is used by GNU packages like coreutils where Y2038 is a problem even now, due to the long lead times and lack of updatability on systems that use these other GNU packages.

So therefore my question seems to be even more important than I
thought, and I'm still asking which Gnulib modules are affected by
this, because I'd need to audit them carefully to see whether the
32-bit MS-Windows build with mingw.org's MinGW could be affected.

There should be no need to audit, because Gnulib still supports platforms that have only 32-bit time_t.

Gnulib is agnostic about time_t width, and is supposed to work even if time_t is 40 bits (which it is on a very few mainframes) or any other width. We regularly test it only on 32- and 64-bit time_t, though.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]