Related articles |
---|
justify use of flex vs lex swl26@cas.org (1993-01-25) |
Re: justify use of flex vs lex jbuck@forney.berkeley.edu (1993-01-25) |
Re: justify use of flex vs lex zstern@adobe.com (1993-01-26) |
Re: justify use of flex vs lex bart@cs.uoregon.edu (1993-01-29) |
Newsgroups: | comp.compilers |
From: | zstern@adobe.com (Zalman Stern) |
Organization: | Adobe Systems Incorporated |
Date: | Tue, 26 Jan 1993 23:30:15 GMT |
Keywords: | lex, flex |
References: | 93-01-178 |
swl26@cas.org (Steve Layten x3451) writes:
[Asks about vendor support of lex.]
My impression from having worked at a UNIX vendor is the only way lex
would get fixed is if USL did the work. Code like lex originates off some
source distribution and then percolates through N layers of source control
and finally makes it into a build. The build is regression tested and so
long as nothing fails, it's shipped. Vendors are loathe to fix something
like lex because they have to merge their fixes the next time they get a
source drop. And given that most people have either learned to work
around the bugs or picked up flex instead, there is little incentive to do
so.
The easy way to get around stupid management restrictions in this case is
to bundle flex with your project's code. Have the build mechanism build
the tool first and you're in business. (If your management asks why you
didn't use lex, they're probably smart enough to understand a detailed
description of how lex is broken...)
--
Zalman Stern zalman@adobe.com (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.