Ken Hornstein <kenh(_at_)pobox(_dot_)com> writes:
Earl Hood mentioned that he was running into problems with "repl"
hanging, and I ran into the same thing as well during some testing
here, so I went and tracked down the problem. Basically, it boils
down to the use of %(putaddr) when "num" is zero.
%(putaddr) uses the "num" register as a field width. If "num" is zero
(and many times it is if you don't explicitly set it), then it ends up
basically performing badly (you would eventually get a whole lot of newlines
in your draft). This has been a problem for approximately forever.
Having this just hang because of a poorly written mh-format file
seems wrong. Suggestions on a good solution? Fixing the format
scanner code so it behaves better is a possibility (but I'm not
sure what "better" is in this case), but I am wondering if the
format code should kick out an error when it runs into this situation.
mh-format says this:
When a function or component escape is interpreted and the result
will be immediately printed, an optional field width can be
specified to print the field in exactly a given number of
characters.
Note the text, "optional field width." Thus, I think that if num is
zero, %(putaddr) should emit its entire contents, subject to any line
length restrictions in play. I don't think it should be an error if the
field width is missing/0 as the documentation clearly states that it is
optional.
--
Bill Wohler <wohler(_at_)newt(_dot_)com> aka
<Bill(_dot_)Wohler(_at_)nasa(_dot_)gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers