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

Previous Next

Full log

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)

Previous Next

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