Corrupted score files with ... symbols

Corrupted score files with ... symbols

[Florian Weimer]

The patch below prevents Gnus from corrupting score files if
`print-level' is ever set to a non-nil value.  This kind of score file
corruption results in the following error message:

gnus-score-load-score-alist: Wrong type argument: listp, \.\.\.

(The fix is to remove the `...' symbol from the score file.  Some data
is lost.)

Okay to commit?

2004-08-23  Florian Weimer  <fw@deneb.enyo.de>

	* gnus-score.el (gnus-score-save): Bind `print-length' to nil, to
	prevent truncation of scoring rules.

	* score-mode.el (gnus-score-pretty-print): Likewise.

Index: gnus-score.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus-score.el,v
retrieving revision 7.12
diff -u -r7.12 gnus-score.el
--- gnus-score.el	20 May 2004 08:02:39 -0000	7.12
+++ gnus-score.el	23 Aug 2004 09:11:47 -0000
@@ -1387,6 +1387,7 @@
 (defun gnus-score-save ()
   ;; Save all score information.
   (let ((cache gnus-score-cache)
+	(print-length nil)
 	entry score file)
     (save-excursion
       (setq gnus-score-alist nil)
Index: score-mode.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/score-mode.el,v
retrieving revision 7.2
diff -u -r7.2 score-mode.el
--- score-mode.el	20 May 2004 08:02:41 -0000	7.2
+++ score-mode.el	23 Aug 2004 09:11:55 -0000
@@ -93,7 +93,8 @@
   (goto-char (point-min))
   (let ((form (read (current-buffer))))
     (erase-buffer)
-    (let ((emacs-lisp-mode-syntax-table score-mode-syntax-table))
+    (let ((emacs-lisp-mode-syntax-table score-mode-syntax-table)
+	  (print-length nil))
       (pp form (current-buffer))))
   (goto-char (point-min)))
 

Re: Corrupted score files with ... symbols

[Katsumi Yamaoka]

>>>>> In <87657agqoz.fsf@deneb.enyo.de>
>>>>>	Florian Weimer <fw@deneb.enyo.de> wrote:

> The patch below prevents Gnus from corrupting score files if
> `print-level' is ever set to a non-nil value.  This kind of score file
> corruption results in the following error message:

> gnus-score-load-score-alist: Wrong type argument: listp, \.\.\.

> (The fix is to remove the `...' symbol from the score file.  Some data
> is lost.)

> Okay to commit?

The change seems to affect pp (or pp-to-string).  Since pp is
being used also in the other Gnus modules, shouldn't we apply
the same change to them, either?

cd gnus/lisp
grep '(pp' *.el

Re: Corrupted score files with ... symbols

[Florian Weimer]

* Katsumi Yamaoka:

> The change seems to affect pp (or pp-to-string).  Since pp is
> being used also in the other Gnus modules, shouldn't we apply
> the same change to them, either?

I'm not sure.  `gnus-prin1', for example, has been deliberately
written to cope with non-nil values of `print-length'.  Some callers
might bind `print-circle' in ddition to `print-length' and try to
print cyclic data structures.

Re: Corrupted score files with ... symbols

[Katsumi Yamaoka]

>>>>> In <877jrqf6xn.fsf@deneb.enyo.de>
>>>>>	Florian Weimer <fw@deneb.enyo.de> wrote:

> * Katsumi Yamaoka:

>> The change seems to affect pp (or pp-to-string).  Since pp is
>> being used also in the other Gnus modules, shouldn't we apply
>> the same change to them, either?

> I'm not sure.  `gnus-prin1', for example, has been deliberately
> written to cope with non-nil values of `print-length'.  Some callers
> might bind `print-circle' in ddition to `print-length' and try to
> print cyclic data structures.

I'm not sure too, but in fact, I saw print-* variables were
sometimes changed from the default values by a mysterious reason
even though I never changed them.  I think binding all print-*
variables to the defaults is better for a prevention for an
accident and the overhead does not impose a burden because pp is
not fast.  Isn't it a good opportunity to clear an anxiety away?
How about making of gnus-pp and gnus-pp-to-string? ;-)

Re: Corrupted score files with ... symbols

[Katsumi Yamaoka]

>>>>> In <b9ysmaevxqq.fsf@jpl.org> Katsumi Yamaoka wrote:

>>>>>> In <877jrqf6xn.fsf@deneb.enyo.de>
>>>>>>	Florian Weimer <fw@deneb.enyo.de> wrote:

>> * Katsumi Yamaoka:

>>> The change seems to affect pp (or pp-to-string).  Since pp is
>>> being used also in the other Gnus modules, shouldn't we apply
>>> the same change to them, either?

>> I'm not sure.  `gnus-prin1', for example, has been deliberately
>> written to cope with non-nil values of `print-length'.  Some callers
>> might bind `print-circle' in ddition to `print-length' and try to
>> print cyclic data structures.

> I'm not sure too, but in fact, I saw print-* variables were
> sometimes changed from the default values by a mysterious reason
> even though I never changed them.  I think binding all print-*
> variables to the defaults is better for a prevention for an
> accident and the overhead does not impose a burden because pp is
> not fast.  Isn't it a good opportunity to clear an anxiety away?
> How about making of gnus-pp and gnus-pp-to-string? ;-)

I've done.  I didn't bind `print-circle' because non-nil value
of it is harmless, and it may be useful since it reduces the
size of the .newsrc.eld file, for example.