justify use of flex vs lex

I need to use flex instead of lex for a job I have that exceeds capacities
of some lex features. I want to put this into a "production" job stream,
and our current "standards" seem to discourage use of public-domain code
in production, the standard managment argument being that we should use
vendor-supported code so we don't have to spend time maintaing the code
ourselves. I must justify the use of this "non-supported" code in
production.


I would appreciate hearing comments from this community regarding
arguments for or against the use of flex vs. the vendor-supplied lex.
Some additional considerations which I think are important are:


      Support across multiple platforms/environments - flex can be ported to
      all of the environments we use, and thus we would be sure to have a
      consistent environment.


      Fewer constraints or "limits" built in.


      I believe that support for flex is "better" than most vendors; how many
      in this list would say that UNIX vendors focus much time or effort in
      keeping their "lex" up to date and bug-free?


Feel free to respond via e-mail or to the group. I'll summarize e-mail
esponses if appropriate, so please indicate in any private communication
if you wish that it not become public.


Thank you for your time.


Steve Layten
--
Steven W. Layten, Senior Engineer
Chemical Abstracts Service, PO Box 3012, Columbus, OH 43210 +1 614 447 3600
INET: swl26@cas.org BITNET: swl26@cas UUCP: osu-cis!chemabs!swl26
[The reality is that lex is still riddled with bugs after over 15 years of
alleged vendor support, while flex is nearly bug-free. When revising
O'Reilly's lex&yacc, I found many lexers needed fiddling to work around lex
bugs, a few I couldn't get to work at all with lex. They all work with flex.
-John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.