Following up on this patch, here's a brief explanation. In
<https://bugs.gnu.org/36597> we were battling with a problem building Emacs
under 32-bit MinGW. The problem was that Gnulib stdint.in.h did this:
# if !((defined __KLIBC__ && defined _INTPTR_T_DECLARED) \
|| (defined __MINGW32__ && defined _INTPTR_T_DEFINED && defined
_UINTPTR_T_DEFINED))
# undef intptr_t
# undef uintptr_t
# ifdef _WIN64
typedef long long int gl_intptr_t;
typedef unsigned long long int gl_uintptr_t;
# else
typedef long int gl_intptr_t;
typedef unsigned long int gl_uintptr_t;
# endif
# define intptr_t gl_intptr_t
# define uintptr_t gl_uintptr_t
# endif
which makes intptr_t 'long', whereas Gnulib inttypes.in.h did this:
#if !defined PRIdPTR
# ifdef INTPTR_MAX
# define PRIdPTR @PRIPTR_PREFIX@ "d"
# endif
#endif
and since MinGW's PRIdPTR is already "d" this leaves it "d". Later when Emacs
code did something like this:
intptr_t ip; ...
printf ("%PRIdPTR, ip);
GCC complained:
warning: format '%d' expects argument of type 'int', but argument 2 has type
'gl_intptr_t' {aka 'long int'} [-Wformat=]
The code ran OK since 'int' and 'long' are the same, but we wanted to squelch
the warning.
