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

Previous Next

Package: emacs;

Reported by: Pip Cet <pipcet <at> gmail.com>

Date: Thu, 11 Jul 2019 14:07:02 UTC

Severity: normal

Tags: patch

Found in version 27.0.50

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


Message #76 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: Tue, 11 Aug 2020 20:00:10 +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 08:30:23 -0700
> 
> >   lisp.h:108:17: note: format string is defined here
> >     108 | #   define pI "ll"
> 
> <https://stackoverflow.com/questions/23718110/error-unknown-conversion-type-character-l-in-format-scanning-long-long> 
> suggests that this is a problem on MinGW, but pI is supposed to be "I64" on that 
> platform, not "ll".

No, it's supposed to be "ll".  The problem is not in lisp.h, it's in
pdumper.c: its declaration of attributes of dump_trace was incorrect
for MinGW.  I fixed that.

The warnings about %d vs gl_intptr_t should be fixed in Gnulib, I
think: why does it use 'long int' instead of 'int' on 32-bit
platforms?  Or maybe the format in pdumper.c should use %ld instead, I
don't know.




This bug report was last modified 4 years and 284 days ago.

Previous Next


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