bug#8033: 24.0.50; Number type error in byte compiler

bug#8033: 24.0.50; Number type error in byte compiler

[Chong Yidong]

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

bug#8033: Not the byte compiler; problem lies deeper

[Michael Welsh Duggan]

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@md5i.com)

bug#8033: Not the byte compiler; problem lies deeper

[Michael Welsh Duggan]

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

    revno: 102793.1.4
    committer: Paul Eggert <eggert@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@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@md5i.com)

bug#8033: Not the byte compiler; problem lies deeper

[Michael Welsh Duggan]

[-- Attachment #1: Type: text/plain, Size: 43 bytes --]

Here is a patch which fixes this problem.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 469 bytes --]

=== 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 */
      {


[-- Attachment #3: Type: text/plain, Size: 42 bytes --]


-- 
Michael Welsh Duggan
(md5i@md5i.com)

bug#8033: Not the byte compiler; problem lies deeper

[Chong Yidong]

Michael Welsh Duggan <md5i@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.

bug#8033: Not the byte compiler; problem lies deeper

[Michael Welsh Duggan]

Chong Yidong <cyd@stupidchicken.com> writes:

> Michael Welsh Duggan <md5i@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@md5i.com)

bug#8033: Not the byte compiler; problem lies deeper

[Michael Welsh Duggan]

Chong Yidong <cyd@stupidchicken.com> writes:

> Michael Welsh Duggan <md5i@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@md5i.com)

bug#8033: Not the byte compiler; problem lies deeper

[Chong Yidong]

Michael Welsh Duggan <md5i@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.