[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36597: 27.0.50; rehash hash tables eagerly in pdumper
From: |
Eli Zaretskii |
Subject: |
bug#36597: 27.0.50; rehash hash tables eagerly in pdumper |
Date: |
Wed, 12 Aug 2020 17:10:34 +0300 |
> Cc: larsi@gnus.org, pipcet@gmail.com, 36597@debbugs.gnu.org
> From: Paul Eggert <eggert@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.)
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, (continued)
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Paul Eggert, 2020/08/11
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Pip Cet, 2020/08/11
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Lars Ingebrigtsen, 2020/08/11
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Eli Zaretskii, 2020/08/11
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Paul Eggert, 2020/08/11
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Eli Zaretskii, 2020/08/11
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Paul Eggert, 2020/08/11
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Eli Zaretskii, 2020/08/11
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Eli Zaretskii, 2020/08/11
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Paul Eggert, 2020/08/11
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper,
Eli Zaretskii <=
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Eli Zaretskii, 2020/08/12
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Paul Eggert, 2020/08/12
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Eli Zaretskii, 2020/08/12
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Andy Moreton, 2020/08/12
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Pip Cet, 2020/08/11
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Eli Zaretskii, 2020/08/11
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Paul Eggert, 2020/08/11
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Andy Moreton, 2020/08/11
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Eli Zaretskii, 2020/08/11