Fix a bug in imap4d parser, add more tests.

* imap4d/io.c (gettok): Fix memory overwrite.
* imap4d/tests/fetch.at: Add checks for HEADER, HEADER.FIELDS,
HEADER.FIELDS.NOT, and TEXT applied to message/rfc822 parts.
* testsuite/spool/msg.mbox: New file.
* testsuite/spool/DISTFILES: Add msg.mbox.

@@ -528,9 +528,9 @@ gettok (struct imap4d_tokbuf *tok, size_t off)
 	return insert_nul (tok, off);
       off++;
     }
-  buf[off++] = 0;
+  insert_nul (tok, off);
   
-  return off;
+  return off + 1;
 }
 
 static void

@@ -14,7 +14,8 @@
 # You should have received a copy of the GNU General Public License
 # along with GNU Mailutils.  If not, see <http://www.gnu.org/licenses/>.
 
-dnl FETCH_CHECK([NAME=`'],[KW=`'],[ARG=`'],[OUTPUT=`'],[MBOX=mbox1],[FILTERS=`'])
+dnl FETCH_CHECK([NAME=`'],[KW=`'],[ARG=`'],[OUTPUT=`'],[MBOX=mbox1],
+dnl             [FILTERS=`'])
 m4_define([FETCH_CHECK],[
 AT_SETUP([$1])
 AT_KEYWORDS([fetch $2])
@@ -324,10 +325,48 @@ bGFyIHN0cmVuZ3RoLCB3aGljaCBpdCBnYXZlIHRvIG15IGphdywKSGFzIGxhc3RlZCB0aGUgcmVz
 dCBvZiBteSBsaWZlLicK
 )])
 
+#         The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part
+#         specifiers can be the sole part specifier or can be prefixed by
+#         one or more numeric part specifiers, provided that the numeric
+#         part specifier refers to a part of type MESSAGE/RFC822.  The
+#         MIME part specifier MUST be prefixed by one or more numeric
+#         part specifiers.
+
+FETCH_CHECK([N.HEADER (text/plain)],[fetch-header-subpart-text fetch18],
+[1 BODY[[1.HEADER]]],
+[* 1 FETCH (BODY[[1.HEADER]] NIL)],
+[msg.mbox])
+
+FETCH_CHECK([N.HEADER (message/rfc822)],[fetch-header-subpart-msg fetch19],
+[1 BODY[[2.HEADER]]],
+[* 1 FETCH (BODY[[2.HEADER]] {406}
+Message-ID: <20111123103317.27412@host.example.org>
+Date: Wed, 23 Nov 2011 10:33:17 +0200
+From: Sergey Poznyakoff <gray@example.org>
+To: <gray@example.com>
+Subject: Re: RFC822 Subtype
+In-reply-to: Your message of Wed, 23 Nov 2011 08:48:16 +0100
+         <87wrar6zzz@example.com>
+References: <87wrar6zzz@example.com>
+X-Envelope-Date: Wed Nov 23 08:33:17 2011
+X-Envelope-Sender: gray@example.org
+
+)],
+[msg.mbox])
+
+FETCH_CHECK([N.HEADER.FIELDS],[fetch-header-fields-subpart fetch20],
+[1 BODY[[2.HEADER.FIELDS (FROM TO)]]],
+[* 1 FETCH (BODY[[2.HEADER.FIELDS (FROM TO)]] {70}
+FROM: Sergey Poznyakoff <gray@example.org>
+TO: <gray@example.com>
+
+)],
+[msg.mbox])
+
 # BODY.PEEK[<section>]<<partial>>
 #                    An alternate form of BODY[<section>] that does not
 #                    implicitly set the \Seen flag.
-FETCH_CHECK([BODY.PEEK[[HEADER]]],[fetch-body-peek-header fetch18],
+FETCH_CHECK([BODY.PEEK[[HEADER]]],[fetch-body-peek-header fetch21],
 [1 BODY.PEEK[[HEADER]]],
 [* 1 FETCH (BODY[[HEADER]] {326}
 Received: (from foobar@nonexistent.net)
@@ -345,7 +384,7 @@ Subject: Jabberwocky
 #                syntax of the resulting untagged FETCH data (RFC822
 #                is returned).
 
-FETCH_CHECK([RFC822],[fetch-rfc822 fetch19],
+FETCH_CHECK([RFC822],[fetch-rfc822 fetch22],
 [1 RFC822],
 [* 1 FETCH (FLAGS (\Seen) RFC822 {1298}
 Received: (from foobar@nonexistent.net)
@@ -398,7 +437,7 @@ And the mome raths outgrabe.
 #                differing in the syntax of the resulting untagged
 #                FETCH data (RFC822.HEADER is returned).
 # FIXME: Should it set \Seen flag?
-FETCH_CHECK([RFC822.HEADER],[fetch-rfc822-header fetch20],
+FETCH_CHECK([RFC822.HEADER],[fetch-rfc822-header fetch23],
 [2 RFC822.HEADER],
 [* 2 FETCH (RFC822.HEADER {328}
 Received: (from bar@dontmailme.org)
@@ -414,14 +453,14 @@ Subject: Re: Jabberwocky
 
 # RFC822.SIZE    The [RFC-822] size of the message.
 
-FETCH_CHECK([RFC822.SIZE],[fetch-rfc822-size fetch21],
+FETCH_CHECK([RFC822.SIZE],[fetch-rfc822-size fetch24],
 [3 RFC822.SIZE],
 [* 3 FETCH (RFC822.SIZE 1611)])
 
 # RFC822.TEXT    Functionally equivalent to BODY[TEXT], differing in
 #                the syntax of the resulting untagged FETCH data
 #                (RFC822.TEXT is returned).
-FETCH_CHECK([RFC822.TEXT],[fetch-rfc822-text  fetch22],
+FETCH_CHECK([RFC822.TEXT],[fetch-rfc822-text  fetch25],
 [2 RFC822.TEXT],
 [* 2 FETCH (FLAGS (\Seen) RFC822.TEXT {219}
 It seems very pretty, but it's *rather* hard to understand!'
@@ -433,7 +472,7 @@ that's clear, at any rate...
 # FAST           Macro equivalent to: (FLAGS INTERNALDATE
 #                RFC822.SIZE)
 
-FETCH_CHECK([FAST],[fetch-fast fetch23],
+FETCH_CHECK([FAST],[fetch-fast fetch26],
 [1 FAST],
 [* 1 FETCH (FLAGS (\Recent) INTERNALDATE "28-Dec-2001 22:18:09 +0000" RFC822.SIZE 1298)],
 [],
@@ -442,11 +481,10 @@ FETCH_CHECK([FAST],[fetch-fast fetch23],
 # FULL           Macro equivalent to: (FLAGS INTERNALDATE
 #                RFC822.SIZE ENVELOPE BODY)
 
-FETCH_CHECK([FULL],[fetch-full fetch24],
+FETCH_CHECK([FULL],[fetch-full fetch27],
 [4 FULL],
 [* 4 FETCH (FLAGS (\Recent) INTERNALDATE "13-Jul-2002 00:50:58 +0000" RFC822.SIZE 3483 ENVELOPE ("Sat, 13 Jul 2002 00:50:58 +0300" "Nested MIME" (("Sergey Poznyakoff" NIL "gray" "example.net")) (("Sergey Poznyakoff" NIL "gray" "example.net")) (("Sergey Poznyakoff" NIL "gray" "example.net")) (("Foo Bar" NIL "foobar" "nonexistent.net")) NIL NIL NIL "<200207122150.g6CLowb05126@example.net>") BODY (("text" "plain" ("name" "msg.21" "charset" "us-ascii") "<5122.1026510654.2@example.net>" "Father William Part I" "7BIT" 351 10)(("application" "octet-stream" ("name" "msg.22") "<5122.1026510654.4@example.net>" "Father William Part II" "base64" 486)(("application" "octet-stream" ("name" "msg.23") "<5122.1026510654.6@example.net>" "Father William Part III" "base64" 490)("application" "octet-stream" ("name" "msg.24") "<5122.1026510654.7@example.net>" "Father William Part IV" "base64" 502) "mixed" NIL NIL NIL) "mixed" NIL NIL NIL) "mixed" NIL NIL NIL))],
 [],
 [fixup_tz])
 
-
 dnl ----------------------------------------------------------------------

 bigto.mbox
 mbox1
 mbox
+msg.mbox
 search.mbox
 sieve.mbox
 relational.mbox

+From gray@example.org Sat Nov 26 22:45:20 2011
+Date: Sat, 26 Nov 2011 22:45:20 +0200
+From: Sergey Poznyakoff <gray@example.org>
+To: <root@example.com>
+Subject: rfc2046
+Content-Type: multipart/mixed; boundary="1595057156-1322340286=:8528"
+MIME-Version: 1.0
+Status: OR
+
+--1595057156-1322340286=:8528
+Content-ID: <20111126224446.8528.1@host.example.org>
+Content-Type: text/plain
+
+An excerpt from RFC 2046 regarding message/rfc822.
+
+
+--1595057156-1322340286=:8528
+Content-Transfer-Encoding: 7bit
+Content-Description: 
+Content-ID: <20111126224446.8528.1@host.example.org>
+Content-Type: message/rfc822; name="1.msg"
+
+Message-ID: <20111123103317.27412@host.example.org>
+Date: Wed, 23 Nov 2011 10:33:17 +0200
+From: Sergey Poznyakoff <gray@example.org>
+To: <gray@example.com>
+Subject: Re: RFC822 Subtype
+In-reply-to: Your message of Wed, 23 Nov 2011 08:48:16 +0100
+         <87wrar6zzz@example.com>
+References: <87wrar6zzz@example.com>
+X-Envelope-Date: Wed Nov 23 08:33:17 2011
+X-Envelope-Sender: gray@example.org
+
+5.2.1.  RFC822 Subtype
+
+   A media type of "message/rfc822" indicates that the body contains an
+   encapsulated message, with the syntax of an RFC 822 message.
+   However, unlike top-level RFC 822 messages, the restriction that each
+   "message/rfc822" body must include a "From", "Date", and at least one
+   destination header is removed and replaced with the requirement that
+   at least one of "From", "Subject", or "Date" must be present.
+
+--1595057156-1322340286=:8528--
+