home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
-
- In article <530@usenix.ORG> std-unix@uunet.uu.net writes:
- -Submitted-by: jsh@usenix.org (Jeffrey S. Haemer)
- - + lint89: This utility is optional, largely because it is
- - controversial for a number of reasons. Obviously, the very name
- - lint89 is painfully bureaucratic. Furthermore, many feel that
- - ANSI C makes it unnecessary; moreover, any remaining required
- - functionality rightfully belongs as an additional option in the
- - c89 (cc) utility. Some point to existing practice. But what is
- - existing practice when the utility's name is lint89? [Editor: On
- - the other hand, it may prove indispensable in detecting
- - portability problems in lex89- and yacc89-generated code.
- - Parenthetically, Draft 10 calls these lex and yacc, but that must
- - just be a temporary oversight; the utilities obligatorily have
- - ANSI C input and output. (One assumes we'll escape c89tags
- - because ctags can be made to work with both flavors.)]
-
- I really do not understand the reasoning behind not just using the
- names "cc", "lint", "lex", etc. The entire software generation system
- needs to work together as an integrated whole. Now that there is an
- official standard for C, any further standardization involving C should
- be connected to standard C. Since the C standard is in almost all ways
- upward-compatible so that "lint", "lex", etc. can be upgraded to support
- standard C and still act as before when fed "old K&R C", so long as the
- software generation system's C compiler understands lex/yacc/whatever
- output there should be no issue here. From the standards point of view
- there should currently be only one notion of what C is.
-
- - D A Gwyn (sporadically acting X3J11/P1003 liaison)
-
- Volume-Number: Volume 21, Number 121
-
-