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