regular expression (and maybe some more). C<buffer> is the read
buffer and C<len> is the number of bytes of data in the buffer.
+ ssize_t next_match;
+
+If C<mexp_expect> returns a match, then C<next_match> points to the
+first byte in the buffer I<after> the fully matched expression. (It
+may be C<-1> which means it is invalid). The next time that
+C<mexp_expect> is called, it will start by consuming the data
+C<buffer[next_match...len-1]>. Callers may also need to read from
+that point in the buffer before calling L<read(2)> on the file
+descriptor. Callers may also set this, for example setting it to
+C<-1> in order to ignore the remainder of the buffer. In most cases
+callers can ignore this field, and C<mexp_expect> will just do the
+right thing when called repeatedly.
+
size_t read_size;
Callers may set this to the natural size (in bytes) for reads from the
C<regexps[].re>, C<regexps[].extra>, C<regexps[].options>, C<ovector>
and C<ovecsize> are passed through to the L<pcre_exec(3)> function.
+=item *
+
+If multiple regular expressions are passed, then they are checked in
+turn and the I<first> regular expression that matches is returned
+I<even if the match happens later in the input than another regular
+expression>.
+
+For example if the input is C<"hello world"> and you pass the two
+regular expressions:
+
+ regexps[0].re = world
+ regexps[1].re = hello
+
+then the first regular expression (C<"world">) may match and the
+C<"hello"> part of the input may be ignored.
+
+In some cases this can even lead to unpredictable matching. In the
+case above, if we only happened to read C<"hello wor">, then the
+second regular expression (C<"hello">) I<would> match.
+
+If this is a concern, combine your regular expressions into a single
+one, eg. C<(hello)|(world)>.
+
=back
=head2 mexp_expect example