GNU bug report logs - #36597
27.0.50; rehash hash tables eagerly in pdumper

Previous Next

Full log

Message #109 received at 36597 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 36597 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#36597: 27.0.50; rehash hash tables eagerly in pdumper
Date: Wed, 12 Aug 2020 12:11:09 -0700

On 8/12/20 7:10 AM, Eli Zaretskii wrote:

> If that module is in our repository only because of MS-Windows, then
> it indeed isn't needed.

OK, I removed it.

> I don't understand why it uses 'long int' 32-bit platforms, it looks
> gratuitous, especially since MinGW itself uses just 'int'.  (Another
> question is why Gnulib thinks it needs to redefine intptr_t, but if
> the redefinition was correct, this would not be especially important.)

As I recall the idea was to not worry about the plethora of buggy intptr_t 
implementations at the time, and just substitute Gnulib's own. Nowadays perhaps 
that decision should be revisited.

I looked into the MinGW situation and the problem seems to be that MinGW defined 
a macro _INTPTR_T_DEFINED that it no longer defines, and Gnulib was keying off 
that no-longer-present macro. I installed a patch for that in Gnulib here:

https://lists.gnu.org/r/bug-gnulib/2020-08/msg00088.html

and migrated the patch into Emacs. Hope it fixes things.


As an aside, we're spending too much time on pdumper.c code that has no effect 
because dump_trace never outputs anything. How about if I remove dump_trace and 
its callers? Although dump_trace may have been useful when the portable dumper 
got developed, it's just a developer time sink now.

Previous Next

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