GNU bug report logs - #33847
27.0.50; emacsclient does not find server socket

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 33847 <at> debbugs.gnu.org, larsi <at> gnus.org, teika <at> gmx.com, ulm <at> gentoo.org
Subject: bug#33847: 27.0.50; emacsclient does not find server socket
Date: Sat, 24 Jul 2021 16:31:21 -0700

[Message part 1 (text/plain, inline)]

> We cannot use these modules on MS-Windows because we have our private
> implementation of malloc/realloc/free in w32heap.c.

In looking into this, I noticed that our current approach has another 
problem, because admin/merge-gnulib avoids Gnulib's malloc-posix module 
so that the Emacs build procedure need not worry about Gnulib's malloc 
interposition on MS-Windows. However, Gnulib relies on the POSIX malloc 
spec in its own use of malloc, so malloc-posix should be present in 
Emacs; this is for the benefit of some platforms that are neither GNU 
nor MS-Windows.

What we should do is (A) have the Emacs tarball contain whatever Gnulib 
memory-allocation modules Gnulib needs, (B) arrange for Gnulib's 
memory-allocation modules to be inactive on MS-Windows, and (C) arrange 
for Emacs's private implementation of malloc/realloc/free to be 
GNU-compatible.

Proposed patches attached to do all this. Patch 4/4 is the one needing 
most scrutiny, since it involves MS-Windows which I don't use.


Some context here. Gnulib's recent memory-allocation changes mostly deal 
with sizes exceeding PTRDIFF_MAX, which is a no-no for obvious reasons 
(POSIX will prohibit this in the next version, I think) and where Gnulib 
assumes malloc etc. will fail. This is of practical concern mostly on 
32-bit platforms (though there's a practical concern with calloc even on 
64-bit platforms).

Similarly, the new year2038 Gnulib code is of practical concern only on 
some 32-bit platforms (namely, GNU/Linux x86 and ARM).


> Can you tell which Gnulib modules are affected by the new
> "--disable-year2038" option?

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

The --disable-year2038 option has an effect only on 32-bit GNU/Linux x86 
and ARM (glibc 2.34 and later). On these platforms, the option affects a 
good many Gnulib modules as well as Emacs source code directly. This is 
because the option affects anything that gets or sets a timestamp from 
the OS. 'stat' syscalls, for example.

As I understand it, MS-Windows switched to 64-bit time_t back in 2005 
(even on 32-bit platforms), and nowadays you have to explicitly request 
32-bit time_t (does anybody do that when building Emacs? I hope not). 
The --disable-year2038 option does not have any effect on MS-Windows, 
because nobody has bothered to add support for that option on that 
platform and I expect and hope that nobody ever will.

The only reason --disable-year2038 might be useful to Emacs is on 
GNU/Linux x86 or ARM, if Emacs is linked to old libraries that require 
time_t to be 32-bit in their ABI. Although I don't know of any such 
libraries being used with Emacs, I haven't checked everything that Emacs 
potentially links to, so there might be an issue there.

Any Emacs executables built with the --disable-year2038 option on 
GNU/Linux x86 or ARM will of course stop working after 2038, so it's not 
an option I recommend.

[0001-Simplify-socket-symlink-attack-checking.patch (text/x-patch, attachment)]

[0002-Update-from-Gnulib-by-running-admin-merge-gnulib.patch (text/x-patch, attachment)]

[0003-By-hand-fixes-for-update-from-Gnulib.patch (text/x-patch, attachment)]

[0004-Port-recent-Gnulib-changes-to-MS-Windows.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.