🚀 go-pugleaf

The nasty bug previously mentioned appears to be due to a bad
interaction with the 822 header parsing library routine called
"Next822Word" (defined in overhead/mail/lib/scan822.c).  Apparently,
this routine was documented to return 0 on error, (although is822Error
might have been more consistent) but this was never checked for by the
date parsing routines.    The fix is a very simple one-liner in
ams/libs/ms/msparse.c:

% diff *msparse.c originals/*msparse.c
54c54
<     while (code822 && code822 != is822End) {
---
>     while (code822 != is822End) {
%

In other words, the while loop in the date parser should check for
code822 getting set to zero.