|
the rfc822_parse_adrlist().
Some explanations seem to be in order here. Let's look at
the code:
386 else if (*s == ';')
387 {
388 if (phraselen)
389 {
390 phrase[phraselen] = 0;
391 add_addrspec (&top, &last, phrase, comment, &commentlen, sizeof (comment) - 1);
392 }
393 else if (commentlen && !last->personal)
394 {
395 comment[commentlen] = 0;
396 last->personal = safe_strdup (comment);
397 }
398 #ifdef EXACT_ADDRESS
399 if (last && !last->val)
Line 399 contains the change; previously, it looked like
this:
399' if (last)
400 last->val = mutt_substrdup (begin, s);
401 #endif
402
403 /* add group terminator */
404 cur = rfc822_new_address ();
405 if (last)
406 {
407 last->next = cur;
408 last = cur;
409 }
410
411 phraselen = 0;
412 commentlen = 0;
413 s++;
414 begin = s;
415 SKIPWS (begin);
416 }
OK, what happens? There are essentially two situations here:
-> We have already parsed a complete address specification
and know about this fact, but there was no new address
information. This is the case if we are parsing
through addresses like
undisclosed-recipients:;
or
recipients: a, b, c,;
(Note the extra ',' before the ';'!)
In this case, some of the other code in rfc822.c has
already filled in last->val, and we really shouldn't
overwrite that with a NULL pointer.
-> The ';' finishes an address spec, like in
recipients: a;
In this case, last is either set by add_addrspec(), or
it has already been set by some of the previous code
(comment handling, ...). Anyway, last->val is still
NULL, so it is correct to write the complete addr spec
to last->val.
|
