GNU bug report logs - #8033
24.0.50; Number type error in byte compiler

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8033 in the body.
You can then email your comments to 8033 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; Number type error in byte compiler
Date: Mon, 14 Feb 2011 00:43:03 -0500

I originally reported this as a Gnus bug, but turns out it's a bug in
the byte compiler.  To reproduce, create a file with the following
contents:

  (defvar foo 1.0)

  (defun foo ()
    (interactive)
    (if (and (equal foo 1.0)
             (equal foo 1))
        (error "Object is `equal' to both a float and an integer")))

Then, in the shell:

~ $ emacs -Q -batch -f batch-byte-compile foo.el
~ $ emacs -Q -batch -l foo.elc -f foo
Object is `equal' to both a float and an integer

The error does not show up in Emacs 23.x, so it must have been
introduced relatively recently on the trunk.



In GNU Emacs 24.0.50.6 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2011-02-14 on furball
Windowing system distributor `The X.Org Foundation', version 11.0.10706000
configured using `configure  'CC=gcc' 'CFLAGS=-g''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.utf8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

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

From: Michael Welsh Duggan <md5i <at> md5i.com>
To: 8033 <at> debbugs.gnu.org
Subject: Not the byte compiler; problem lies deeper
Date: Mon, 14 Feb 2011 01:58:00 -0500

Just thought I'd chime in to let you know that the problem is deeper
than the bye compiler.  My bug report at 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8034 gives an example that
triggers this bug without involving byte compiling at all.  I've tried
tracing through Fread, and it almost seems as if it is the print
representation that is changing, not the value itself.

-- 
Michael Welsh Duggan
(md5i <at> md5i.com)

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

From: Michael Welsh Duggan <md5i <at> md5i.com>
To: 8033 <at> debbugs.gnu.org
Subject: Re: bug#8033: Not the byte compiler; problem lies deeper
Date: Mon, 14 Feb 2011 06:22:17 -0500

Using bisection, I have determined that the error is introduced in this
pair of commits.

    revno: 102793.1.4
    committer: Paul Eggert <eggert <at> cs.ucla.edu>
    branch nick: gnulib-2b
    timestamp: Sat 2011-01-08 17:20:28 -0800
    message:
      Regenerate.
    removed:
      lib/dummy.c
    added:
      lib/dtoastr.c
      lib/ftoastr.c
      lib/ftoastr.h
      lib/intprops.h
      lib/ldtoastr.c
      m4/c-strtod.m4
    modified:
      aclocal.m4
      configure
      lib/Makefile.in
      lib/gnulib.mk
      m4/gnulib-cache.m4
      m4/gnulib-comp.m4
      src/config.in
    ------------------------------------------------------------
    revno: 102793.1.3
    committer: Paul Eggert <eggert <at> cs.ucla.edu>
    branch nick: gnulib-2b
    timestamp: Sat 2011-01-08 17:18:39 -0800
    message:
      Use gnulib's ftoastr module.
    modified:
      ChangeLog
      Makefile.in
      src/ChangeLog
      src/print.c

-- 
Michael Welsh Duggan
(md5i <at> md5i.com)

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

From: Michael Welsh Duggan <md5i <at> md5i.com>
To: 8033 <at> debbugs.gnu.org
Subject: Re: bug#8033: Not the byte compiler; problem lies deeper
Date: Mon, 14 Feb 2011 15:25:42 -0500

[Message part 1 (text/plain, inline)]

Here is a patch which fixes this problem.

[Message part 2 (text/x-patch, inline)]

=== modified file 'src/print.c'
*** src/print.c	2011-02-14 15:39:19 +0000
--- src/print.c	2011-02-14 20:24:00 +0000
***************
*** 1063,1068 ****
--- 1063,1070 ----
        /* Generate the fewest number of digits that represent the
  	 floating point value without losing information.  */
        dtoastr (buf, FLOAT_TO_STRING_BUFSIZE, 0, 0, data);
+       /* Force a decimal point even if integer */
+       width = 1;
      }
    else			/* oink oink */
      {

[Message part 3 (text/plain, inline)]

-- 
Michael Welsh Duggan
(md5i <at> md5i.com)

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Michael Welsh Duggan <md5i <at> md5i.com>
Cc: 8033 <at> debbugs.gnu.org
Subject: Re: bug#8033: Not the byte compiler; problem lies deeper
Date: Mon, 14 Feb 2011 16:52:32 -0500

Michael Welsh Duggan <md5i <at> md5i.com> writes:

> Here is a patch which fixes this problem.
>
> *** src/print.c	2011-02-14 15:39:19 +0000
> --- src/print.c	2011-02-14 20:24:00 +0000
> ***************
> *** 1063,1068 ****
> --- 1063,1070 ----
>         /* Generate the fewest number of digits that represent the
>   	 floating point value without losing information.  */
>         dtoastr (buf, FLOAT_TO_STRING_BUFSIZE, 0, 0, data);
> +       /* Force a decimal point even if integer */
> +       width = 1;
>       }
>     else			/* oink oink */
>       {

Thanks, but could you explain why printing the float 1.0 as "1" can
cause this problem in Gnus?  The code in Gnus passes the actual Lisp
objects around, so the printer shouldn't be involved.

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

From: Michael Welsh Duggan <md5i <at> md5i.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 8033 <at> debbugs.gnu.org
Subject: Re: bug#8033: Not the byte compiler; problem lies deeper
Date: Mon, 14 Feb 2011 17:08:27 -0500

Chong Yidong <cyd <at> stupidchicken.com> writes:

> Michael Welsh Duggan <md5i <at> md5i.com> writes:
>
>> Here is a patch which fixes this problem.
>>
>> *** src/print.c	2011-02-14 15:39:19 +0000
>> --- src/print.c	2011-02-14 20:24:00 +0000
>> ***************
>> *** 1063,1068 ****
>> --- 1063,1070 ----
>>         /* Generate the fewest number of digits that represent the
>>   	 floating point value without losing information.  */
>>         dtoastr (buf, FLOAT_TO_STRING_BUFSIZE, 0, 0, data);
>> +       /* Force a decimal point even if integer */
>> +       width = 1;
>>       }
>>     else			/* oink oink */
>>       {
>
> Thanks, but could you explain why printing the float 1.0 as "1" can
> cause this problem in Gnus?  The code in Gnus passes the actual Lisp
> objects around, so the printer shouldn't be involved.

Because the byte compiler uses something like `print' in order to create
the forms in the elc file, and some "1.0"'s in the
`gnus-buffer-configuration' get rendered as "1" in the elc file.  Hence,
when the .elc file gets loaded instead of the .el file (and why not, it
is more recent), you get the bogus integer value instead of the float
value.

This is also why this issue will not occur for people who have not
bootstrapped, since gnus-win.el has not changed.  It does not get
recompiled, and as a result the elc file left behind by a previous
compile still has the "1.0" values in it.

-- 
Michael Welsh Duggan
(md5i <at> md5i.com)

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

From: Michael Welsh Duggan <md5i <at> md5i.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 8033 <at> debbugs.gnu.org
Subject: Re: bug#8033: Not the byte compiler; problem lies deeper
Date: Mon, 14 Feb 2011 17:10:56 -0500

Chong Yidong <cyd <at> stupidchicken.com> writes:

> Michael Welsh Duggan <md5i <at> md5i.com> writes:
>
>> Here is a patch which fixes this problem.
>>
>> *** src/print.c	2011-02-14 15:39:19 +0000
>> --- src/print.c	2011-02-14 20:24:00 +0000
>> ***************
>> *** 1063,1068 ****
>> --- 1063,1070 ----
>>         /* Generate the fewest number of digits that represent the
>>   	 floating point value without losing information.  */
>>         dtoastr (buf, FLOAT_TO_STRING_BUFSIZE, 0, 0, data);
>> +       /* Force a decimal point even if integer */
>> +       width = 1;
>>       }
>>     else			/* oink oink */
>>       {

Oh, and I should mention that without this patch, width gets used as an
uninitialized variable after the if clause, which is why it is pretty
random whether we get 1.0 or 1 in the output.

-- 
Michael Welsh Duggan
(md5i <at> md5i.com)

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Michael Welsh Duggan <md5i <at> md5i.com>
Cc: 8033 <at> debbugs.gnu.org
Subject: Re: bug#8033: Not the byte compiler; problem lies deeper
Date: Mon, 14 Feb 2011 17:25:31 -0500

Michael Welsh Duggan <md5i <at> md5i.com> writes:

> Because the byte compiler uses something like `print' in order to create
> the forms in the elc file, and some "1.0"'s in the
> `gnus-buffer-configuration' get rendered as "1" in the elc file.  Hence,
> when the .elc file gets loaded instead of the .el file (and why not, it
> is more recent), you get the bogus integer value instead of the float
> value.
>
> This is also why this issue will not occur for people who have not
> bootstrapped, since gnus-win.el has not changed.  It does not get
> recompiled, and as a result the elc file left behind by a previous
> compile still has the "1.0" values in it.

Ah yes, of course.

I've committed your patch.  Thanks.

Previous Next

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