[Top][All Lists]

[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 <address@hidden> 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"") <address@hidden>
   which presumably violates RFC822.
2. bbdb-rfc822-addresses calls rfc822-addresses, which turns the header
   into this string:
   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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]