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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Daniel Colascione <dancol <at> dancol.org>
Cc: larsi <at> gnus.org, 36597 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: bug#36597: 27.0.50; rehash hash tables eagerly in pdumper
Date: Wed, 12 Aug 2020 22:28:28 +0300

> Cc: larsi <at> gnus.org, pipcet <at> gmail.com, 36597 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Wed, 12 Aug 2020 12:11:09 -0700
> 
> 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 think _INTPTR_T_DEFINED is still being used, but only by MinGW64.  I
use mingw.org's MinGW, where that macro was never used.

However, both MinGW flavors typedef intptr_t as 'int', not 'long int',
on 32-bit platforms.

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

It does here, thanks.  I hope someone will be able to make sure
MinGW64 builds are not adversely affected (I don't think they should
be).

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

I have no opinion on this, but I'd like to hear from Daniel (CC'ed)
what he thinks.

Previous Next

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