|
From: | Paul Eggert |
Subject: | bug#36597: 27.0.50; rehash hash tables eagerly in pdumper |
Date: | Wed, 12 Aug 2020 12:11:09 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |