bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Eli Zaretskii
Subject: bug#33847: 27.0.50; emacsclient does not find server socket
Date: Sat, 24 Jul 2021 11:25:37 +0300

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





reply via email to

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