[patch-0.94.4i.tlr.rfc822_leak.1] Fixing a memory leak in

[patch-0.94.4i.tlr.rfc822_leak.1] Fixing a memory leak in
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.