duane@anasaz.UUCP (Duane Morse) (01/02/91)
lint1 bombs out on some of our bigger programs; as far as I can tell, lint1 has a fixed number of structures it can keep track of, and when the limit is reached, it gives up. I read a review of a lint replacement called FlexeLint from Gimpel Software, and am interested in reviews. Ostensibly it would get around lint1's problem by growing dynamically (so says the literature), and it is supposed to help find errors which lint doesn't. Are there any FlexeLint users out there who would care to comment on the product? -- Duane Morse e-mail: duane@anasaz (or ... asuvax!anasaz!duane) (602) 861-7609
jtc@van-bc.wimsey.bc.ca (J.T. Conklin) (01/04/91)
In article <3424@anasaz.UUCP> duane@anasaz.UUCP (Duane Morse) writes: >I read a review of a lint replacement called FlexeLint from Gimpel >Software, and am interested in reviews. Ostensibly it would get >around lint1's problem by growing dynamically (so says the literature), >and it is supposed to help find errors which lint doesn't. Are there >any FlexeLint users out there who would care to comment on the product? FlexeLint does have some compiled in defaults, but since its distributed in shrouded source form you can increase them and re-compile when you run up against those limits. I've linted some _huge_ programs and never had any problems. I bought FlexeLint about 6 months after I converted to ANSI C, as the lint I was using didn't understand function prototypes. It has been money well spent. The thing I like about FlexeLint is that each of the 500+ error messages can be turned off and on individually. They even can be tuned to be on or off depending on what function is being called. For example: -esym(534,printf,fprintf,sprintf) Tells lint not to bother telling me about the times I don't use the return value of printf, fprintf, or sprintf. Another nice thing it does is to check the arguments to printf and scanf against its format specification. This is very convienient, but oftentimes I use functions that call vprintf for error messages, etc. I have written Gimpel to suggest they implement the /* PRINTFLIKEn */ and /* SCANFLIKEn */ lint directives found in the SysV.4 make. Another wart I just discovered (see a followup posting I made in comp.unix.programmer) was that FlexeLint, like lint, does poor job when trying to determine whether a variable hasnot been set before used. Fortunately, gcc -Wall catches it, but FlexeLint is so good in all other respects, I expected better. --jtc -- J.T. Conklin jtc@wimsey.bc.ca, ...!{uunet,ubc-cs}!van-bc!jtc
mcdaniel@adi.com (Tim McDaniel) (01/04/91)
FlexeLint is a wonderful tool. It catches a great number of possible errors, and each message can be turned on or off (globally, or on a per-symbol, per-file, or inline basis). You can control the machine and compiler models via options (longs are N bytes, ints are M bytes, sizeof is/is not unsigned, et cetera). I also use it to parse a source file if SUN OS 4.1 cc (ecch!) gives me a undecodable message. It's available in shrouded source for a number of platforms. -- Tim McDaniel Applied Dynamics Int'l.; Ann Arbor, Michigan, USA Work phone: +1 313 973 1300 Home phone: +1 313 677 4386 Internet: mcdaniel@adi.com UUCP: {uunet,sharkey}!amara!mcdaniel
harrison@necssd.NEC.COM (Mark Harrison) (01/05/91)
In article <3424@anasaz.UUCP>, duane@anasaz.UUCP (Duane Morse) writes: > I read a review of a lint replacement called FlexeLint from Gimpel > Software, and am interested in reviews. I have been a flexelint users since it first came out on PCs, and was a beta tester when it moved to Unix. I could go on and on, but three items can sum up its strengths. 1. It does a lot of validations. printf() formats matching args, indentation anomolies, precedence oddities, K&R/Ansi portability considerations, etc. 2. Any check can be turned on or off. One of the main problems with regular lint is that there are usually so many messages to sort through. 3. Great support. James Gimpel was at Bell Labs for a number of years, and now he teaches at U. Penn. He is very open to suggestions and generally does an excellent job. Hope this helps... -- Mark Harrison harrison@necssd.NEC.COM (214)518-5050 {necntc, cs.utexas.edu}!necssd!harrison standard disclaimers apply...
gordon@osiris.cso.uiuc.edu (John Gordon) (01/07/91)
"Shrouded Source" is source code that is fully compilable, but all of the identifiers (variables & function names) have been replaced with totally unreadable strings. For example, if you have the line: int num_records, employee_num; it could be changed into: int JcqX_8iM, A8lrh7; In general, the purpose of "Shrouding" is to provide source code that can be ported and compiled, but not really understood or modified. Other things that shrouding can do: Replace all integer constants with hex or octal constants change for's, while's, and if's to goto's destroy the nice format of the original source (i.e. have the shrouded source be 1 big long line) And probably some other things that I forgot. --- John Gordon Internet: gordon@osiris.cso.uiuc.edu #include <disclaimer.h> gordon@cerl.cecer.army.mil #include <clever_saying.h>
mcdaniel@adi.com (Tim McDaniel) (01/08/91)
harrison@necssd.NEC.COM (Mark Harrison) writes:
3. Great support. James Gimpel was at Bell Labs for a number of
years, and now he teaches at U. Penn. He is very open to suggestions
and generally does an excellent job.
Oh, yeah, forgot about that. When we got FlexeLint, we immediately
ran into a bug. FlexeLint would report an error on
a = (*(long (*)(void))tt)();
or anything else with calling a pointer to function with prototype
(void). I called up Gimpel Software and left a message. Within a day
or so, I got a call back from Jim Gimpel hisself, wanting to know the
symptoms. Later, he called back and gave me the file name and line
number to change, and what to change it to. He then explained the
technical details of what had happened ("we subtracted 1 to denote a
(void) prototype, but forgot to add 1 to compensate here", more or
less).
He's sharp and he gives good support. 8-) (Of course, the president
of the company has better things to do with his time than tech
support, but it makes the customer feel good.)
--
Tim McDaniel Applied Dynamics Int'l.; Ann Arbor, Michigan, USA
Work phone: +1 313 973 1300 Home phone: +1 313 677 4386
Internet: mcdaniel@adi.com UUCP: {uunet,sharkey}!amara!mcdaniel
klein@uncw.UUCP (Tony Klein) (01/12/91)
Anyone out there know if there is a PD version of lint that will work with Ansi-C (gcc). We just started Data Structures and our current version of lint is not compatible. An FTP site would be nice. Thanks in advance, Tony Klein klein@uncw.uucp