[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#453: 23.0.60; rfc822-bad-address: wrong-type-argument error
From: |
Stephen Berman |
Subject: |
bug#453: 23.0.60; rfc822-bad-address: wrong-type-argument error |
Date: |
Wed, 27 Aug 2008 12:38:05 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
On Tue, 26 Aug 2008 17:30:05 -0400 Chong Yidong <cyd@stupidchicken.com> wrote:
> Sorry for the delay in replying.
>
>> I was reading a newsgroup with Gnus, typed `n'
>> (gnus-summary-next-unread-article) to read the next article[1], and
>> got a wrong-type-argument error. The backtrace is attached. The
>> error occurs in rfc822-bad-address, when the first argument of
>> narrow-to-region, rfc822-address-start, is nil. The value is nil at
>> this point because rfc822-addresses calls rfc822-nuke-whitespace
>> before rfc822-address-start is assigned an initial value.
>
> I don't see how rfc822-address-start could be nil. The code sets it to
> (point) just before the call to rfc822-bad-address. Could you further
> explain your reasoning?
The error occurs before that setq can be called, because
rfc822-bad-address is also called from rfc822-nuke-whitespace, and at
this point rfc822-address-start is nil. In more detail:
1. bbdb-rfc822-addresses is trying to parse this header:
(""Groß, Werner"") <W.F.Gross@t-online.de>
which presumably violates RFC822.
2. bbdb-rfc822-addresses calls rfc822-addresses, which turns the header
into this string:
(""Groß
and, after let-binding but before setq-ing rfc822-address-start,
3. calls rfc822-nuke-whitespace, which further truncates the header to:
(
and then calls
4. rfc822-bad-address, which tries to call narrow-to-region with
rfc822-address-start, which is still nil, as the beginning of the
region: BZZT!
> (By the way, next time you mail a patch, please try not to change
> whitespaces; that makes the patch very difficult to read. Thanks.)
Sorry. That was the result of doing indent-region, which I assume means
the existing indentation does not conform to Emacs conventions. Would
it be appropriate to submit a separate patch to correct that?
Steve Berman