greg@turbo.atl.ga.us (Greg Montgomery) (12/18/90)
I'm looking for a DOS lint that's compatible with C++ and ANSI C,
specifically TC++, if it matters. Does anyone know of such a program,
shareware or commercial??? The most common lint I've heard of is
PC-lint, but I don't believe it supports C++. Any ideas??
Thanks...
----
Greg Montgomery | Montgomery Consultants, Inc. | Atlanta, Georgia, U.S.A
Internet: greg@turbo.atl.ga.us | Home of the '96
UUCP: {rutgers,ogcise,gatech}!emory!turbo!greg | Olympics!davidm@uunet.UU.NET (David S. Masterson) (12/20/90)
>>>>> On 18 Dec 90 02:14:43 GMT, greg@turbo.atl.ga.us (Greg Montgomery) said:
Greg> I'm looking for a DOS lint that's compatible with C++ and ANSI C,
Greg> specifically TC++, if it matters. Does anyone know of such a program,
Greg> shareware or commercial??? The most common lint I've heard of is
Greg> PC-lint, but I don't believe it supports C++. Any ideas?? Thanks...
Isn't the C++, itself, enough of a LINT program?? LINT is usually used to
detect potential problems in the source code that the compiler would not
normally check for. C++, though, seems to check for everything that a LINT
program would, so what's the need?
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"hansen@pegasus.att.com (Tony L. Hansen) (12/20/90)
< Isn't the C++, itself, enough of a LINT program?? LINT is usually used
< to detect potential problems in the source code that the compiler would
< not normally check for. C++, though, seems to check for everything
< that a LINT program would, so what's the need?
Off the top of my head, here are some of the things that a lint++ could do
that C++ is incapable of doing:
o check the types of the arguments to printf- and scanf-like functions
o know about functions which never return
o check for falling through switch cases
o look for external symbols that could be declared static
o find unused external variables
These are all capabilities of the version of lint in System V release 4.
Most capabilities cannot be folded into the C++ compiler. It might be
possible to introduce some of them through language modifications. Others
might possibly be introduced through #pragma's. But it's also unclear whether
any of these SHOULD be caught by the compiler.
So, yes, there is a need for a lint++.
Tony Hansen
att!pegasus!hansen, attmail!tony
hansen@pegasus.att.comhansen@pegasus.att.com (Tony L. Hansen) (12/20/90)
<< Isn't the C++, itself, enough of a LINT program?? LINT is usually used
<< to detect potential problems in the source code that the compiler would
<< not normally check for. C++, though, seems to check for everything
<< that a LINT program would, so what's the need?
< Off the top of my head, here are some of the things that a lint++ could
< do that C++ is incapable of doing:
< o check the types of the arguments to printf- and scanf-like functions
In addition to printf- and scanf-like functions, are an entire class of other
functions, such as execl(). All of these functions are ones which prototypes
cannot completely describe, but COULD be described in some other pattern
language that a tool such as lint++ could understand. For example, execl(),
which takes a series of char* arguments, could be declared as:
int execl(char*, char* +)
where the "+" has the usual egrep meaning of "1-or-more". A function which
took a series of paired arguments, one a double and the other an integer,
could possibly be declared with a pattern such as:
int foo({double, integer}+)
Consider also a function which optionally takes a 3rd parameter depending on
what the value of the 2nd parameter is, such as open(). Right now, the
prototype for open() says to not check the 3rd parameter at all because it is
declared with an ellipsis. Through a more expressive prototyping language, it
WOULD be possible to check that 3rd parameter, and even check to see if it
should even be there. It's difficult to see how C++ could possibly be
enhanced to this degree, but other tools could probably be developed which
could do the checking.
The reason I mentioned printf() and scanf() in particular is that there is a
ton of existing C code being compiled with a C++ compiler. It sure would be
nice if that code can be as completely checked by the C++ compiler as it is
by lint. But since it can't, that's where lint++ would come in.
< o know about functions which never return
< o check for falling through switch cases
G++ has these capabilities. But it does so using features outside of the C++
language, as I suggest below.
< o look for external symbols that could be declared static
< o find unused external variables
It's been pointed out to me that one could write a script using nm and uniq,
among other shell tools, to do these. This sounds great; if you do, call it
the first release of lint++. :-) Note however, that this would have to be
done as a post-processing-pass after the code is compiled.
< These are all capabilities of the version of lint in System V release
< 4. Most capabilities cannot be folded into the C++ compiler. It might
< be possible to introduce some of them through language modifications.
< Others might possibly be introduced through #pragma's. But it's also
< unclear whether any of these SHOULD be caught by the compiler.
< So, yes, there is a need for a lint++.
It's also possible that most of this checking could be enabled with some
extra warning options to CC/g++/tcc/ztc/whatever-compiler-you-use, so a
separate tool would not be necessary. But be aware, adding these features is
definitely going beyond the language definition (and entering the lint-light
zone! :-) ) It would also be nice if any extensions added to support such
checking could be standardized.
Tony Hansen
att!pegasus!hansen, attmail!tony
hansen@pegasus.att.competerli@ux5.lbl.gov (12/21/90)
In article <1990Dec20.042841.16639@cbnewsk.att.com> hansen@pegasus.att.com (Tony L. Hansen) writes: >Off the top of my head, here are some of the things that a lint++ could do >that C++ is incapable of doing: > > o check the types of the arguments to printf- and scanf-like functions > o know about functions which never return Wow! Has the Halting Problem been solved ? :-) Peter Li