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: 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: bug#36597: 27.0.50; rehash hash tables eagerly in pdumper
Date: Tue, 11 Aug 2020 16:43:16 -0700

[Message part 1 (text/plain, inline)]

On 8/11/20 11:35 AM, Eli Zaretskii wrote:
> It doesn't, because we avoid the Gnulib inttypes module on MinGW.

In that case perhaps I should revert the change that added the Gnulib inttypes 
module, as MS-Windows is the only currently-active platform with PRIdPTR etc. 
problems that I've heard of.

> I don't understand why it's needed; there's nothing wrong with MinGW's
> inttypes.h header.

I don't know what the problems with MS-Windows are or were. Perhaps they're 
fixed on all development environments we know about. That would suggest 
reverting the inttypes change too.

Does the attached simplification pacify GCC on MinGW? If so, that could be 
combined with reverting the inttypes change.

Does the following standalone program compile OK with 'gcc -Wall' on MinGW? If 
so, why does the same thing not work when compiling Emacs? The error message you 
quoted in Bug#36597#67 suggests that PRIdPTR is "d" whereas intptr_t is 'long' 
which means the following program should run afoul of MinGW.

#include <inttypes.h>
#include <stdio.h>
char buf[1000];
intptr_t ip;
int main (void) {
  return sprintf (buf, "%"PRIdPTR, ip);
}

[pdumper.diff (text/x-patch, attachment)]

Previous Next

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