[comp.mail.mh] MH 6.7[.1] on NeXT release 2.0

louie@sayshell.umd.edu (Louis A. Mamakos) (01/18/91)

I noticed that sometime after I installed the 2.0 release of the NeXT system
software, and patched and re-compiled MH 6.7 -> 6.7.1, that the date parser 
seems to be broken.  This manifests itself both in the dp program as well
as the varous month{} year{} and day{} functions in the format files.

I've tracked it down to the zotnet/tws routines, obviously, and into some
horrible state table.  Any ideas?

louie

louie@sayshell.umd.edu (Louis A. Mamakos) (02/03/91)

I posted a question to comp.mail.mh a few days ago asking about MH
date scanning problems on a NeXT running the 2.0 release of software.
Not hearing any replies, I jumped right in.

Ever since I upgraded my NeXT from 1.0 to the 2.0 release of software,
and rebuilt MH when the patches were released, I had problems with the
date parsing routines.  Specifically, the stuff in zotnet/tws.  This
problem would manifiest itself in the 'dp' program as well as mhl,
scan, inc, sortm, etc.

Pretty annoying.

I broke out GDB and traced though an invocation of dp to discover where
the problem was; it was in the lex generated dtimep.c module.  Hmmm..

Just yesterday I decided to run lex on another machine to see if its
lex-generated lexical analyzer worked any differently.  Unfortunately, I
first tried to use flex, but this didn't work out too well because of
the fact that the out of lex is massaged by sed.  

I then lex'ed and sed'ed dtimep.lex on an Ultrix system, compiled the
result on the NeXT, and all is (finally) well now.  Diff'ing the NeXT
generated dtimep.c with the Ultrix generated dtimep.c revealed not a
few differences in the generated tables.  I didn't think it useful to
try to figure out just exactly what the difference between the two is,
or what it means.

So, comp.sys.next'ers:

	- Something is broken (or at least much different) with the lex
	supplied by NeXT under 2.0 as compared to 1.0.

and comp.mail.mh'ers,

	- It would be nice if flex could be used; or rather, that sed 
	was NOT used to massage the output of lex when bulding MH.  This
	would help ensure a bit more portability between different platforms.

louie