From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: teika@gmx.com, 33847@debbugs.gnu.org, larsi@gnus.org, ulm@gentoo.org
Subject: bug#33847: 27.0.50; emacsclient does not find server socket
Date: Sat, 24 Jul 2021 11:25:37 +0300 [thread overview]
Message-ID: <83v950yv7i.fsf@gnu.org> (raw)
In-Reply-To: <5f457b50-c1bd-4856-33c7-f85edf111bd0@cs.ucla.edu> (message from Paul Eggert on Sat, 24 Jul 2021 00:48:25 -0700)
> Cc: larsi@gnus.org, teika@gmx.com, 33847@debbugs.gnu.org, ulm@gentoo.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 24 Jul 2021 00:48:25 -0700
>
> On 7/23/21 11:23 PM, Eli Zaretskii wrote:
>
> > why in conjunction with this particular issue?
>
> It's typically better to sync to a single coherent version of Gnulib,
> than to take bits and pieces from different versions of Gnulib. That way
> one needn't worry about version mismatch.
Yes, but making changes in most/all Gnulib while fixing a minor issue
in a single auxiliary program is IMO too much, and stretches this
principle way beyond any reasonable limit. So I'd prefer to make
these Gnulib updates a separate changeset, if that's feasible.
> >> Although I fixed the glitches Eli noted, the other Gnulib changes may
> >> need further changes to Emacs's Microsoft-related code.
> >
> > Which of the Gnulib changes might need that, please?
>
> I said that more as boilerplate than as careful analysis. But in looking
> at the patch more carefully, there may be issues in nt/gnulib-cfg.mk
> where you have to set the following appropriately for MS-Windows:
>
> OMIT_GNULIB_MODULE_realloc-gnu
> OMIT_GNULIB_MODULE_realloc-posix
>
> The realloc-posix module supplies a 'realloc' that conforms to POSIX
> (i.e., it sets errno when it fails, and it refuses to allocate anything
> larger than PTRDIFF_MAX in size).
>
> The realloc-gnu module in addition makes sure that 'realloc' is
> compatible with GNU realloc (i.e., realloc (NULL, 0) returns nonnull
> when it succeeds).
>
> The new file lib/realloc.c arranges for a replacement realloc on
> platforms where realloc-posix and/or realloc-gnu discover that the
> system realloc doesn't match glibc realloc in behavior.
We cannot use these modules on MS-Windows because we have our private
implementation of malloc/realloc/free in w32heap.c. Any problems with
errno and return values for zero-sized allocations must be handled by
our own code there (we could borrow the ideas from Gnulib, of course).
> The msdos directory may need to do something similar.
That's a different port of Emacs and a different libc, so the results
are different.
> There may be other issues, but these are the ones that jump out at me.
Can you tell which Gnulib modules are affected by the new
"--disable-year2038" option? This might have direct effect on how
Emacs is built with mingw.org's MinGW (which is what I use), and in
general to the entire issue of supporting old 32-bit versions of
MS-Windows.
> Hmm, come to think of it, does Emacs already arrange to avoid the
> problematic realloc behavior areas? If so, we can avoid using
> realloc-gnu and realloc-posix, which would simplify the patch a bit.
How would Emacs arrange to avoid these problems? I could take a look
if I knew what I should look for.
Thanks.
next prev parent reply other threads:[~2021-07-24 8:25 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-23 9:48 bug#33847: 27.0.50; emacsclient does not find server socket Ulrich Mueller
2018-12-23 16:20 ` Ulrich Mueller
2018-12-25 21:02 ` Paul Eggert
2018-12-25 23:29 ` Ulrich Mueller
2018-12-26 0:24 ` Paul Eggert
2018-12-26 2:27 ` Ulrich Mueller
2018-12-26 6:59 ` Paul Eggert
2018-12-26 15:14 ` Ulrich Mueller
2018-12-26 18:32 ` Paul Eggert
2018-12-28 6:37 ` Ulrich Mueller
2018-12-30 6:47 ` Paul Eggert
2018-12-27 3:38 ` Richard Stallman
2018-12-27 16:42 ` Paul Eggert
2018-12-27 17:13 ` Paul Eggert
2018-12-28 6:19 ` Ulrich Mueller
2018-12-28 6:35 ` Paul Eggert
2018-12-28 6:51 ` Ulrich Mueller
2018-12-30 6:44 ` Paul Eggert
2019-01-20 17:59 ` Ulrich Mueller
2019-02-10 8:37 ` Ulrich Mueller
2019-02-10 9:48 ` Eli Zaretskii
2020-08-19 11:05 ` Lars Ingebrigtsen
2020-08-21 21:28 ` Paul Eggert
2020-08-22 7:24 ` Ulrich Mueller
2020-08-22 7:33 ` Andreas Schwab
2020-08-22 7:45 ` Ulrich Mueller
2020-08-22 8:00 ` Eli Zaretskii
2020-08-22 17:51 ` Paul Eggert
2020-08-22 7:59 ` Eli Zaretskii
2020-08-22 17:55 ` Paul Eggert
2020-08-22 18:30 ` Eli Zaretskii
2020-08-22 21:20 ` Paul Eggert
2020-08-23 5:41 ` Eli Zaretskii
2021-07-22 13:08 ` Lars Ingebrigtsen
2021-07-22 16:45 ` Eli Zaretskii
2021-07-22 17:05 ` Lars Ingebrigtsen
2021-07-22 17:30 ` Eli Zaretskii
2021-07-23 11:31 ` Lars Ingebrigtsen
2021-07-23 11:38 ` Lars Ingebrigtsen
2021-07-23 23:58 ` Paul Eggert
2021-07-24 6:23 ` Eli Zaretskii
2021-07-24 7:48 ` Paul Eggert
2021-07-24 8:25 ` Eli Zaretskii [this message]
2021-07-24 23:31 ` Paul Eggert
2021-07-25 6:32 ` Eli Zaretskii
2021-07-25 16:22 ` Paul Eggert
[not found] ` <a0688fd6-9e73-73d8-6138-3280981abcb5@cs.ucla.edu>
2021-07-25 16:34 ` Eli Zaretskii
2021-10-04 6:45 ` Paul Eggert
2021-07-25 7:27 ` Eli Zaretskii
2021-07-24 10:11 ` Lars Ingebrigtsen
2021-07-24 19:37 ` Paul Eggert
2021-07-23 11:58 ` Eli Zaretskii
2021-07-22 18:30 ` Ulrich Mueller
2019-04-27 1:41 ` Teika Kazura
2019-04-27 7:56 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83v950yv7i.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=33847@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=larsi@gnus.org \
--cc=teika@gmx.com \
--cc=ulm@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).