From owner-freebsd-hackers Thu Nov 28 14:12:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA16670 for hackers-outgoing; Thu, 28 Nov 1996 14:12:34 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA16662 for ; Thu, 28 Nov 1996 14:12:30 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA01125; Thu, 28 Nov 1996 14:55:33 -0700 From: Terry Lambert Message-Id: <199611282155.OAA01125@phaeton.artisoft.com> Subject: Re: Lex/Yacc question To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 28 Nov 1996 14:55:33 -0700 (MST) Cc: terry@lambert.org, hackers@freebsd.org In-Reply-To: <11590.849149149@time.cdrom.com> from "Jordan K. Hubbard" at Nov 27, 96 06:45:49 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > PS: Why isn't there a Lex or Yacc FAQ? > > Because they both have more than ample manuals in the 4.4 doc set? I > dunno - I never really saw a need for FAQs, and I've written quite a > few parsers (including the entire parser for an ANSI C interpreter I > wrote a few years back). It's very straight-forward to use both tools > if you understand the basics of parser operation, and if you don't > think you probably don't really need to use Lex and Yacc anyway. ;-) I've written a number of parsers, too. Nonen of them needed: KEYWORD rest of stuff to end of line Like the "HELO" keyword in RFC821 requires...: ------- telnet smtp.lambert.org smtp Trying 137.190.16.16... Connected to smtp.lambert.org. Escape character is '^]'. 220 smtp.lambert.org Sendmail 4.1/SMI-4.1.1 ready at Thu, 28 Nov 96 14:52:19 MST helo foo foo foo 250 smtp.lambert.org Hello foo foo foo (host.lambert.org), pleased to meet you quit 221 smtp.lambert.org closing connection Connection closed by foreign host. ------- This is for historical compatability with hand-coded RFC821 parsers, implemented as a C++ encapsulation class for an RFC821 transport subclassed from a transport facility: class RFC821_channel : protected Transport { enum { STATE_PENDING, // no connection STATE_READY, // connected, no HELO/EHLO STATE_HELLO, // seen HELO ... }; private: int state; /* current command state*/ public: ... }; Then I subclass TCP/IP, NITS, X.25, etc. from this... The RFC822 is an envelope parsing (input), cannonizaton (output) mechanism. RFC1341/RFC1342 is a subclass of the RFC822 envelope class for formatting the body pointed to by the envelope class using RFC822 envelope header items... ie: MIME-Version: 1.0 Content-type: audio/basic Content-transfer-encoding: base64 The "MIME-Version:" header from 1341 also needs "text to end of line" recognition. I'm not working on an RFC1341 lexing/grammar (yet). I'm astonished that no one has done this all before. It seems so obvious... Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.