+Unfortunately, if the Reply-to: header is
+.I not
+present, the output line
+will be something like:
+.PP
+.RS 5
+.nf
+My From User <from@example.com>To: My From User <from@example.com>
+.fi
+.RE
+.PP
+What went wrong? When performing the test for the
+.B if
+clause (%<), the component is not output because it is considered an
+argument to the
+.B if
+statement (so the rule about not starting with % applies). But the component
+escape in our
+.B else
+statement (everything after the `%|') is
+.I not
+an argument to anything;
+it begins with a %, and thus the value of that component is output.
+This also has the side effect of setting the
+.I str
+register, which is later picked up by the (\fIformataddr\fR\^) function
+and then output by (\fIputaddr\fR\^). The example format string above
+has another bug: there should always be a valid width value in the
+.I num
+register when (\fIputaddr\fR\^) is called, otherwise bad formatting can take
+place.
+.PP
+The solution is to use the (\fIvoid\fR\^) function; this will prevent the
+function or component from outputting any text. With this in place (and
+using (\fIwidth\fR\^) to set the
+.I num
+register for the width) a better implementation would look like:
+.PP
+.RS 3
+.nf
+%(formataddr %<{reply-to}%|%(void{from})%(void(width))%(putaddr To: )
+.fi
+.RE
+.PP
+It should be noted here that the side effects of function and component
+escapes are still in force and, as a result, each component test in the
+.B if-elseif-else-endif
+clause sets the
+.I str
+register.
+.PP
+As an additional note, the (\fIformataddr\fR\^) and (\fIconcataddr\fR\^)
+functions have special behavior when it comes to the
+.I str
+register. The starting point of the register is saved and is used to
+build up entries in the address list.
+.PP
+You will find the
+.IR fmttest (1)
+utility invaluable when debugging problems with format strings.
+.SS Examples
+With all the above in mind, here is a breakdown of the default format string for