[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: Sat, 24 Jul 2021 16:31:21 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

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.

Attachment: 0001-Simplify-socket-symlink-attack-checking.patch
Description: Text Data

Attachment: 0002-Update-from-Gnulib-by-running-admin-merge-gnulib.patch
Description: Text Data

Attachment: 0003-By-hand-fixes-for-update-from-Gnulib.patch
Description: Text Data

Attachment: 0004-Port-recent-Gnulib-changes-to-MS-Windows.patch
Description: Text Data

reply via email to

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