[Top][All Lists]

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

bug#36597: 27.0.50; rehash hash tables eagerly in pdumper

From: Paul Eggert
Subject: bug#36597: 27.0.50; rehash hash tables eagerly in pdumper
Date: Tue, 11 Aug 2020 16:43:16 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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);

Attachment: pdumper.diff
Description: Text Data

reply via email to

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