nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (05/20/91)
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.