home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!hal.com!darkstar.UCSC.EDU!cats.ucsc.edu!isbell
- From: isbell@cats.ucsc.edu (Art Isbell)
- Newsgroups: comp.sys.next.programmer
- Subject: Re: NeXT lex
- Message-ID: <1iq8s9INN1f5@darkstar.UCSC.EDU>
- Date: 10 Jan 93 22:44:25 GMT
- References: <1993Jan9.232243.14902@pellns.alleg.edu>
- Organization: Cubic Solutions - NeXT software development and consulting
- Lines: 23
- NNTP-Posting-Host: si.ucsc.edu
-
-
- In article <1993Jan9.232243.14902@pellns.alleg.edu> sunthej@alleg.edu writes:
-
- [ description of lex problem deleted ]
-
- Although I don't claim to be a lex expert, I seem to have stumbled across a
- very irritating NeXT 2.1 and 3.0 lex bug: lex doesn't seem to grok '_' in a
- range of characters making defining C variable names as tokens kinda tough.
- NeXT lex treats '_' as a space character thus returning separate tokens before
- and after all occurrences of '_' :-( Replacing all '_' with other characters
- (e.g., '>', '<', etc.) returns correct tokens.
-
- Has anyone else been able to successfully search for tokens containing the '_'
- character using NeXT's lex? Maybe I'm doing something wrong. Meanwhile, I've
- downloaded the latest flex and bison to see whether their output can legally be
- included in commercial apps. I think the FSF's policy may have changed to
- permit this, but I'm not sure. Anyone else know for sure?
- --
-
- Art Isbell Cubic Solutions
- NeXT Registered Developer #745 NeXT software development and consulting
- NeXTmail: isbell@cats.UCSC.EDU Voice: (408)335-1154
- USmail: 95018-9442 Fax: (408)335-2515
-