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

[Michael Welsh Duggan <md5i@md5i.com>]

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)