🚀 go-pugleaf

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