GNU bug report logs - #36597
27.0.50; rehash hash tables eagerly in pdumper

Previous Next

Full log

Message #103 received at 36597 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: larsi <at> gnus.org, 36597 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#36597: 27.0.50; rehash hash tables eagerly in pdumper
Date: Wed, 12 Aug 2020 17:10:34 +0300

> Cc: larsi <at> gnus.org, pipcet <at> gmail.com, 36597 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Tue, 11 Aug 2020 16:43:16 -0700
> 
> [1:text/plain Hide]
> 
> 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.

If that module is in our repository only because of MS-Windows, then
it indeed isn't needed.

> > 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.

I see no problems in MinGW headers with PRIdPTR nor with intptr_t.

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

The warnings disappeared because you installed a change that  no
longer uses the GCC warning options which triggered them.  So I'm
unsure how you'd like me to test the patch, please elaborate.

> 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.

The problem is not with MinGW's definition of intptr_t: it is
typedef'ed as 'int' in 32-bit builds in the MinGW headers.  The
problem is not with intptr_t, it's with its Gnulib equivalent:

  pdumper.c:1229:6: warning: format '%d' expects argument of type 'int', but argument 4 has type 'gl_intptr_t' {aka 'long int'} [-Wformat=]

It complains about gl_intptr_t, not intptr_t.  That's because Gnulib's
stdint.h does this:

  #  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

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

Previous Next

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