Any C/C++ LINT type checking recomendations

We have a large code base, mainly C but with some C++ which we wish to check
for
existing issues in an effort to be proactive.

I have downloaded the open source GLINT program but am having big problems
trying to get it to run.

I will be looking at PC-Lint at http://www.gimpel.com/

Does anyone have any other recommendations, it can be commercial s/w for
this ?
Also Perl scripts would be good as well to run over the source as an
alternative.

Many thanks

re: Any C/C++ LINT type checking recomendations

* Thus spoke Greg Roberts <gregroberts@citectNOSPAM.com>:

Hallo,
[color=blue]
> We have a large code base, mainly C but with some C++ which we wish to
> check for existing issues in an effort to be proactive.[/color]
[color=blue]
> I have downloaded the open source GLINT program but am having big problems
> trying to get it to run.[/color]

glint?

$ man glint

| NAME
| glint - GLINT/Permedia video driver

Do you mean splint? Splint doesn't work with C++ code, see
<http://splint.org/faq.html#quest5>.
[color=blue]
> I will be looking at PC-Lint at http://www.gimpel.com/[/color]

Afaik its the best lint (for C and C++ code) out there.


[f'up2 -> poster]

Wolfgang.
--
"Erfahrungen -- das sind die vernarbten Wunden unserer Dummheit."
-- John Osborne

re: Any C/C++ LINT type checking recomendations

Greg Roberts wrote:[color=blue]
>
> We have a large code base, mainly C but with some C++ which we
> wish to check for existing issues in an effort to be proactive.
>
> I have downloaded the open source GLINT program but am having
> big problems trying to get it to run.
>
> I will be looking at PC-Lint at http://www.gimpel.com/
>
> Does anyone have any other recommendations, it can be
> commercial s/w for this ? Also Perl scripts would be good as
> well to run over the source as an alternative.[/color]

Don't know about GLINT. SPLINT is free and good, but only handles
C. PC-Lint will cost you about $200 (US) and will handle C++ and
C.

Turning these things loose on an existing code is likely to be
unproductive, especially if it is a large code base, because of
the volume of nits to pick. Use on new modules will be very
productive.

Congratulations. This is the first legitimate c.l.c c.l.c++
crosspost I have seen.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

re: Any C/C++ LINT type checking recomendations

Greg Roberts wrote:
[color=blue]
> We have a large code base, mainly C but with some C++ which we wish to check
> for
> existing issues in an effort to be proactive.[/color]

lint and lint-like programs are annoying to the point of uselessness.
They consistently warn about things that /are not wrong/, /never have
been wrong/, and /are not even dangerous/. There's one example that
sticks out in my mind:

int x = 1;

/* code */

if (x) return y;

will /always/ generate a warning with a lint-like program. Why? Because
x is not a `boolean' in lint's view of the world, even though the
relevant standards expressly and specifically allow scalars (such as x)
to function in a boolean context. lint is wrong, the standards are right
(axiomatically), and lint hasn't been fixed.

Also, remember that lint cannot be trusted to `schedule' or `prioritize'
warnings: Using gets() is seen as just as bad as using an int in a
boolean context. (I hope you know how bad gets() is. I hope it's not
polluted C++ as well.)

All that said, splint is good for C but it won't work for C++: splint
allows you to pass in arguments on the command line that will make it
not generate certain classes of warnings. It's the only lint-a-like I
will use, but I don't develop C++.

So, in short, know the limits of your tools.

--
My address is yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
Note: Rot13 and convert spelled-out numbers to numerical equivalents.

re: Any C/C++ LINT type checking recomendations

Greg Roberts wrote:[color=blue]
> We have a large code base, mainly C but with some C++ which we wish to check
> for
> existing issues in an effort to be proactive.
>
> I have downloaded the open source GLINT program but am having big problems
> trying to get it to run.
>
> I will be looking at PC-Lint at http://www.gimpel.com/
>[/color]

As far as I know, no good free C++ lint program exists. I have been
thinking seriously about make one for the GNU project, but haven't had
the time yet. My basic idea is that it should basically be a parser with
easily extendable rules and actions that can be defined by a simple
language in a configuration file. All sorts of things should of course
come predefined.

/David

re: Any C/C++ LINT type checking recomendations

apologies, yes splint under win32

almost impossible to get all the includes and options correct

"Wolfgang Kaufmann" <wk-usenet-200401@theparallax.com> wrote in message
news:slrnc1pv21.41a.wk-usenet-200401@news.theparallax.net...[color=blue]
> * Thus spoke Greg Roberts <gregroberts@citectNOSPAM.com>:
>
> Hallo,
>[color=green]
> > We have a large code base, mainly C but with some C++ which we wish to
> > check for existing issues in an effort to be proactive.[/color]
>[color=green]
> > I have downloaded the open source GLINT program but am having big[/color][/color]
problems[color=blue][color=green]
> > trying to get it to run.[/color]
>
> glint?
>
> $ man glint
>
> | NAME
> | glint - GLINT/Permedia video driver
>
> Do you mean splint? Splint doesn't work with C++ code, see
> <http://splint.org/faq.html#quest5>.
>[color=green]
> > I will be looking at PC-Lint at http://www.gimpel.com/[/color]
>
> Afaik its the best lint (for C and C++ code) out there.
>
>
> [f'up2 -> poster]
>
> Wolfgang.
> --
> "Erfahrungen -- das sind die vernarbten Wunden unserer Dummheit."
> -- John Osborne[/color]

re: Any C/C++ LINT type checking recomendations

I incorrectly said lint where i meant splint, and our env. was MS Visual
C/C++ 6.0 .

Yes you all have mentioned what i found, really hard work to get these to
work
on an existing code base (as i don't really want to have to play with
headers & system headers adnusium) .

Even one expensive tool like C++ Test (U$3500) doesn't look at the MS DSP
files to determine headers to search.

I suspect just adding some basic rules into some Perl scripts will probably
offer the most payback.

Regards

"Greg Roberts" <gregroberts@citectNOSPAM.com> wrote in message
news:IZ5Tb.38619$Wa.33527@news-server.bigpond.net.au...[color=blue]
> We have a large code base, mainly C but with some C++ which we wish to[/color]
check[color=blue]
> for
> existing issues in an effort to be proactive.
>
> I have downloaded the open source GLINT program but am having big problems
> trying to get it to run.
>
> I will be looking at PC-Lint at http://www.gimpel.com/
>
> Does anyone have any other recommendations, it can be commercial s/w for
> this ?
> Also Perl scripts would be good as well to run over the source as an
> alternative.
>
> Many thanks
>
>[/color]

re: Any C/C++ LINT type checking recomendations

On Sun, 01 Feb 2004 21:53:01 -0700, August Derleth <see@sig.now>
wrote:
[color=blue]
> int x = 1;
>
> /* code */
>
> if (x) return y;
>
>will /always/ generate a warning with a lint-like program. Why? Because
>x is not a `boolean' in lint's view of the world, even though the
>relevant standards expressly and specifically allow scalars (such as x)
>to function in a boolean context. lint is wrong, the standards are right
>(axiomatically), and lint hasn't been fixed.[/color]

Lint doesn't need fixing in this case - it's doing exactly what it's
supposed to do. If I were reviewing someone's code which used this
statement, I would suggest that they change it to

if (x != 0) return y;

--
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

re: Any C/C++ LINT type checking recomendations

On Mon, 02 Feb 2004 10:56:51 -0700, Alan Balmer <albalmer@att.net>
wrote:
[color=blue][color=green]
>> if (x) return y;
>>
>>will /always/ generate a warning with a lint-like program. Why? Because
>>x is not a `boolean' in lint's view of the world, even though the
>>relevant standards expressly and specifically allow scalars (such as x)
>>to function in a boolean context. lint is wrong, the standards are right
>>(axiomatically), and lint hasn't been fixed.[/color]
>
>Lint doesn't need fixing in this case - it's doing exactly what it's
>supposed to do. If I were reviewing someone's code which used this
>statement, I would suggest that they change it to
>
>if (x != 0) return y;[/color]

But why? The C++ standard is quite clear on how this is supposed to
behave. Lint, and MSVC++.NET, BTW, are both wrong.

Of course, if x is not a scalar type, then an error (not a warning)
should be generated.


--
Bob Hairgrove
NoSpamPlease@Home.com

re: Any C/C++ LINT type checking recomendations

Bob Hairgrove wrote:[color=blue]
>
> But why? The C++ standard is quite clear on how this is supposed to
> behave. Lint, and MSVC++.NET, BTW, are both wrong.
>[/color]

Wrong? None of them say that it's an error. They say that it is bad
style. Which it is.
[color=blue]
> Of course, if x is not a scalar type, then an error (not a warning)
> should be generated.
>[/color]

They are _not_ generating error messages. You don't understand what lint
is about.

/David

re: Any C/C++ LINT type checking recomendations

Alan Balmer wrote:[color=blue]
> On Sun, 01 Feb 2004 21:53:01 -0700, August Derleth <see@sig.now>
> wrote:
>[color=green]
>> int x = 1;
>>
>> /* code */
>>
>> if (x) return y;
>>
>> will /always/ generate a warning with a lint-like program. Why?
>> Because x is not a `boolean' in lint's view of the world, even
>> though the relevant standards expressly and specifically allow
>> scalars (such as x) to function in a boolean context. lint is wrong,
>> the standards are right (axiomatically), and lint hasn't been fixed.[/color]
>
> Lint doesn't need fixing in this case - it's doing exactly what it's
> supposed to do. If I were reviewing someone's code which used this
> statement, I would suggest that they change it to
>
> if (x != 0) return y;[/color]

And I would change it to

if (0 != x) return y;

At least that was taught to me in programming paranoia school.

BTW the above (if (X) bla) is not bad style (I do nor recall any technical
reason for it) but I think it is rather idiomatic code, and there is nothing
wrong with it.

--
Attila aka WW

re: Any C/C++ LINT type checking recomendations

In article <bvo2kk$i1p$1@newstree.wise.edt.ericsson.se>,
"Attila Feher" <attila.feher@lmf.ericsson.se> wrote:
[color=blue]
> Alan Balmer wrote:[color=green]
> > On Sun, 01 Feb 2004 21:53:01 -0700, August Derleth <see@sig.now>
> > wrote:
> >[color=darkred]
> >> int x = 1;
> >>
> >> /* code */
> >>
> >> if (x) return y;
> >>
> >> will /always/ generate a warning with a lint-like program. Why?
> >> Because x is not a `boolean' in lint's view of the world, even
> >> though the relevant standards expressly and specifically allow
> >> scalars (such as x) to function in a boolean context. lint is wrong,
> >> the standards are right (axiomatically), and lint hasn't been fixed.[/color]
> >
> > Lint doesn't need fixing in this case - it's doing exactly what it's
> > supposed to do. If I were reviewing someone's code which used this
> > statement, I would suggest that they change it to
> >
> > if (x != 0) return y;[/color]
>
> And I would change it to
>
> if (0 != x) return y;
>
> At least that was taught to me in programming paranoia school.[/color]

Please don't do this.

First, it is pointless. There are people who write "0 == x" instead of
"x == 0" to get an error message if they write "=" instead of "==", but
for "!=" this makes no sense. Second, it makes your code less readable
which in itself will increase the number of undetected errors. Third, I
sincerely hope that you use a debugger to step through your code at
least once, so an error like that would be detected immediately. Fourth,
"if (0 == x)" wouldn't pass any decent code review for the reasons
above, but neither would "if (x = 0)".

re: Any C/C++ LINT type checking recomendations

Christian Bau wrote:

<snip>
[color=blue]
> There are people who write "0 == x" instead of
> "x == 0" to get an error message if they write "=" instead of "==", but
> for "!=" this makes no sense.[/color]

Er, 0 != x makes exactly as much sense as x != 0
[color=blue]
> Second, it makes your code less readable
> which in itself will increase the number of undetected errors.[/color]

Whether it's less readable is arguable; if it helps people to get used to
the idea of placing constants on the left of comparisons, then - on
platforms with lousy compilers - it could *reduce* the number of undetected
errors.
[color=blue]
> Third, I
> sincerely hope that you use a debugger to step through your code at
> least once, so an error like that would be detected immediately.[/color]

And yet they so often aren't.
[color=blue]
> Fourth,
> "if (0 == x)" wouldn't pass any decent code review for the reasons
> above, but neither would "if (x = 0)".[/color]

I wouldn't raise any objections to if(0 == x) at a code review.


--
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

re: Any C/C++ LINT type checking recomendations

On Mon, 02 Feb 2004 10:56:51 -0700, in comp.lang.c , Alan Balmer
<albalmer@att.net> wrote:
[color=blue][color=green]
>> if (x) return y;
>>
>>will /always/ generate a warning with a lint-like program. Why? Because
>>x is not a `boolean' in lint's view of the world, even though the
>>relevant standards expressly and specifically allow scalars (such as x)
>>to function in a boolean context. lint is wrong, the standards are right
>>(axiomatically), and lint hasn't been fixed.[/color]
>
>Lint doesn't need fixing in this case - it's doing exactly what it's
>supposed to do. If I were reviewing someone's code which used this
>statement, I would suggest that they change it to
>
>if (x != 0) return y;[/color]

Thats merely obfuscating a perfectly clear expression.

And I agree with August that lint is incorrect - lint should not be
complaining about legal constructs.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

re: Any C/C++ LINT type checking recomendations

"Richard Heathfield" <dontmail@address.co.uk.invalid> wrote in message
news:bvp87s$bmg$3@titan.btinternet.com...[color=blue]
>
> Er, 0 != x makes exactly as much sense as x != 0[/color]

To a compiler, yes. If you have learned to think like one, congratulations.
[color=blue]
> I wouldn't raise any objections to if(0 == x) at a code review.[/color]

But neither would you to if (!x), I hope.

Peter

re: Any C/C++ LINT type checking recomendations

Peter Pichler wrote:
[color=blue]
> "Richard Heathfield" <dontmail@address.co.uk.invalid> wrote in message
> news:bvp87s$bmg$3@titan.btinternet.com...[color=green]
>>
>> Er, 0 != x makes exactly as much sense as x != 0[/color]
>
> To a compiler, yes. If you have learned to think like one,
> congratulations.[/color]

Um... um... thank you! (?!?!?)
[color=blue]
>[color=green]
>> I wouldn't raise any objections to if(0 == x) at a code review.[/color]
>
> But neither would you to if (!x), I hope.[/color]

Depends on the house style, of course (as does the 0 == x one, actually!).
But my own preference is to reserve (x) and (!x) for where x clearly has
Boolean intent, e.g. if(PrinterReady), while(!finished), and so on.

--
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

re: Any C/C++ LINT type checking recomendations

Attila Feher wrote:
[color=blue]
> And I would change it to
>
> if (0 != x) return y;
>
> At least that was taught to me in programming paranoia school.
>
> BTW the above (if (X) bla) is not bad style (I do nor recall any technical
> reason for it) but I think it is rather idiomatic code, and there is nothing
> wrong with it.
>[/color]

The idiom 'if (x) bla;' had certain advantages over the
construct 'if (0 != x) bla;' before compilers grew up. A
number of compilers I used circa K&R used to compile a
compare rather than a test. Nowadays there is no advantage
and the second version is more readable. The one line
statement has a problem though should you ever want to place
a breakpoint on the 'return';

re: Any C/C++ LINT type checking recomendations

Mark McIntyre wrote:[color=blue]
>
> And I agree with August that lint is incorrect - lint should not be
> complaining about legal constructs.
>[/color]

Why should that be? Isn't it the compilers responsibility to
complain about none legal constructs?

re: Any C/C++ LINT type checking recomendations

On Tue, 3 Feb 2004 22:44:13 +0000 (UTC), in comp.lang.c , Richard
Heathfield <dontmail@address.co.uk.invalid> wrote:
[color=blue]
>Christian Bau wrote:
>
><snip>
>[color=green]
>> There are people who write "0 == x" instead of
>> "x == 0" to get an error message if they write "=" instead of "==", but
>> for "!=" this makes no sense.[/color]
>
>Er, 0 != x makes exactly as much sense as x != 0[/color]

indeed.
but you're less likely to miss out the ! in != than the = in ==, which
was CB's point, I suspect.


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

re: Any C/C++ LINT type checking recomendations

Richard Heathfield wrote:[color=blue]
> Christian Bau wrote:
>
> <snip>
>[color=green]
> > There are people who write "0 == x" instead of "x == 0" to get
> > an error message if they write "=" instead of "==", but for
> > "!=" this makes no sense.[/color]
>[/color]
.... snip ...[color=blue]
>[color=green]
> > "if (0 == x)" wouldn't pass any decent code review for the
> > reasons above, but neither would "if (x = 0)".[/color]
>
> I wouldn't raise any objections to if(0 == x) at a code review.[/color]

Nor would I, nor to "if (0 != x)". In fact I would be more likely
to complain about use of "if (x == 0)".

Just stirring the pot with a vote - minor troll.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

re: Any C/C++ LINT type checking recomendations

Mark McIntyre wrote:[color=blue]
>
> And I agree with August that lint is incorrect - lint should not be
> complaining about legal constructs.
>[/color]

Then you don't understand what lint is about.

/David

re: Any C/C++ LINT type checking recomendations

Mark McIntyre <markmcintyre@spamcop.net> wrote in message news:[color=blue]
> And I agree with August that lint is incorrect - lint should not be
> complaining about legal constructs.[/color]

Just because something is 'legal' (not really an adequate word in this
sense) doesn't mean that it's the correct thing to do, does it?

re: Any C/C++ LINT type checking recomendations

On Tue, 03 Feb 2004 23:41:47 +0000, Mark McIntyre
<markmcintyre@spamcop.net> wrote:
[color=blue]
>
>And I agree with August that lint is incorrect - lint should not be
>complaining about legal constructs.[/color]

I think you're confusing the roles of lint and the compiler.

--
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

re: Any C/C++ LINT type checking recomendations

Mark McIntyre wrote:[color=blue]
>[/color]
.... snip ...[color=blue]
>
> And I agree with August that lint is incorrect - lint should not
> be complaining about legal constructs.[/color]

It is not. It is warning about possibly suspicious constructs,
which is a different world.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

re: Any C/C++ LINT type checking recomendations

On Wed, 04 Feb 2004 11:03:08 +0100, in comp.lang.c , David Rasmussen
<david.rasmussen@gmx.net> wrote:
[color=blue]
>Mark McIntyre wrote:[color=green]
>>
>> And I agree with August that lint is incorrect - lint should not be
>> complaining about legal constructs.[/color]
>
>Then you don't understand what lint is about.[/color]

There's no "what lint's about" stuff here. I'm not into the
metaphysical aspects of toolsets. :-)
As far as I'm concerned lint's a tool, If its doesn't do what I want,
then its either
a) the wrong tool or
b) a badly implemented tool.

I happen to believe its the right tool. but IMHO a C code checker that
complains about correct C is badly implemented.



--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

re: Any C/C++ LINT type checking recomendations

On Wed, 04 Feb 2004 08:36:14 -0700, in comp.lang.c , Alan Balmer
<albalmer@att.net> wrote:
[color=blue]
>On Tue, 03 Feb 2004 23:41:47 +0000, Mark McIntyre
><markmcintyre@spamcop.net> wrote:
>[color=green]
>>
>>And I agree with August that lint is incorrect - lint should not be
>>complaining about legal constructs.[/color]
>
>I think you're confusing the roles of lint and the compiler.[/color]

I don't. I don't espcially care to argue about it but I'd just make
the point that a tool that ostensibly is intended to help clean up
your code, but which fills stdout with reams of inaccurate or
misleading error messages, is worse than useless.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

re: Any C/C++ LINT type checking recomendations

On Wed, 04 Feb 2004 15:43:06 GMT, in comp.lang.c , CBFalconer
<cbfalconer@yahoo.com> wrote:
[color=blue]
>Mark McIntyre wrote:[color=green]
>>[/color]
>... snip ...[color=green]
>>
>> And I agree with August that lint is incorrect - lint should not
>> be complaining about legal constructs.[/color]
>
>It is not. It is warning about possibly suspicious constructs,
>which is a different world.[/color]

???
I can understand complaining about
if(x=11)

but whats suspicious about
if(x)


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

re: Any C/C++ LINT type checking recomendations

Mark McIntyre wrote:
[color=blue]
>
> I don't. I don't espcially care to argue about it but I'd just make
> the point that a tool that ostensibly is intended to help clean up
> your code, but which fills stdout with reams of inaccurate or
> misleading error messages, is worse than useless.[/color]

lint ... | filter_out_the_error_i_dont_like

re: Any C/C++ LINT type checking recomendations

Mark McIntyre wrote:
[color=blue]
> On Wed, 04 Feb 2004 15:43:06 GMT, in comp.lang.c , CBFalconer
> <cbfalconer@yahoo.com> wrote:
>[color=green]
>>Mark McIntyre wrote:[color=darkred]
>>>[/color]
>>... snip ...[color=darkred]
>>>
>>> And I agree with August that lint is incorrect - lint should not
>>> be complaining about legal constructs.[/color]
>>
>>It is not. It is warning about possibly suspicious constructs,
>>which is a different world.[/color]
>
> ???
> I can understand complaining about
> if(x=11)
>
> but whats suspicious about
> if(x)
>
>[/color]

Warning: This could be substantially incorrect, or incorrectly phrased.
Corrections are most welcome.

Lint has a separate boolean type which can only be generated by logical
operators, and conditional expressions are supposed to have boolean type in
lint world. x may or may not satisfy that constraint. If it doesn't, lint
complains. That this annoys you is not lint's concern. lint was born in
academia with a different purpose in mind.

Part of the idea behind lint (atleast initially) was stricter type checking
(which is now commonly acknowledged to be a very wise thing indeed) so that
more errors are caught by static analysis. As has been correctly
mentioned, lint has a totally different purpose from a C compiler. What is
legal C is not necessarily a correct program. lint and its future
derivatives try to bridge the gap between "what you said" and "what you
want done". This is an admirable and extremely difficult (if not
impossible) goal.

I haven't been a big fan of lint as it does produce too much clutter, and
its stricter standards are almost impossible to adhere to by any human
coder. To be fair, the primary driving force behind lint wasn't
necessarily usability in real world. To quote from:
http://www.cs.virginia.edu/evans/pubs/tr628.ps

<quote>
Although LCLint is intended to be a pragmatic and useful tool, the primary
motivation behind its development is to investigate the possibilities of
using specifications to do lightweight static checks on source code. By
developing LCLint, we hope to learn if using specifications to check source
code can be a practical and effective way of improving software quality. We
also hope to gain an understanding of how the desire for static code
checkers may influence the design of formal specification languages and the
adoption of programming conventions. By using LCLint in a variety of ways,
we hope to learn if and how such a tool can enable better software
engineering, reduce the effort required to develop good programs, and help
us understand and maintain existing programs.
</quote>

However, splint provides command line options that can control most of the
annoyances, and when used appropriately improves productivity and code
quality considerably (in my case atleast).

August Derleth is incorrect in asserting:[color=blue]
> lint and lint-like programs are annoying to the point of uselessness.
> They consistently warn about things that /are not wrong/, /never have
> been wrong/, and /are not even dangerous/. There's one example that
> sticks out in my mind:
>
> int x = 1;
>
> /* code */
>
> if (x) return y;
>
> will always generate a warning with a lint-like program. Why? Because
> x is not a `boolean' in lint's view of the world, even though the
> relevant standards expressly and specifically allow scalars (such as x)
> to function in a boolean context. lint is wrong, the standards are right
> (axiomatically), and lint hasn't been fixed.[/color]

The fact is that lint is trying to enforce a subset of standard C that it
considers to be safer/better. Just because something is correct according
to the standard doesn't mean it has to be correct in lint's view of the
world. If this were true, lint's utility is highly questionable.

Also in splint, +boolint +ptrnegate +boolops +charint will take care of that
annoyance (mostly).

-nrk.

--
Remove devnull for email

re: Any C/C++ LINT type checking recomendations

Mark McIntyre wrote:[color=blue]
> <cbfalconer@yahoo.com> wrote:[color=green]
>> Mark McIntyre wrote:[color=darkred]
>>>[/color]
>>... snip ...[color=darkred]
>>>
>>> And I agree with August that lint is incorrect - lint should
>>> not be complaining about legal constructs.[/color]
>>
>> It is not. It is warning about possibly suspicious constructs,
>> which is a different world.[/color]
>
> ???
> I can understand complaining about
> if(x=11)
>
> but whats suspicious about
> if(x)[/color]

and "if (x == 11)", which is pristine. Another thing to watch for
is "if (x = y + z)" which is also valid, but suspicious. Yet that
last is a very useful construct. The first is normally caught by
insisting that "if (CONST == variable)" be written with the CONST
first.

Note that every snippet above is legal C code.

Assuming x is an int in both cases, the first allows for no
misconceptions barring a typo. The second _could_ be a typo or
other error, even though it is valid code. Valid code does NOT
mean correct code. So you usually have several choices - write
code that cannot be misconstrued, as in the third, annotate the
statement to suppress the warning, or use various configuration
possibilities to suppress all warnings of this type.

Splint, lint, pclint etc. should not be used before the source
passes the compiler. So there should be no gross syntax errors.
By now you are interested in having your attention drawn to areas
that *may* deserve further review.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

re: Any C/C++ LINT type checking recomendations

lilburne <lilburne@godzilla.net> wrote:
[color=blue]
> Mark McIntyre wrote:
>[color=green]
> > I don't. I don't espcially care to argue about it but I'd just make
> > the point that a tool that ostensibly is intended to help clean up
> > your code, but which fills stdout with reams of inaccurate or
> > misleading error messages, is worse than useless.[/color]
>
> lint ... | filter_out_the_error_i_dont_like[/color]

s/error/dozens_of_errors, by which time your command line will be a
couple of dozen screen lines long.

Richard

re: Any C/C++ LINT type checking recomendations

Richard Bos wrote:[color=blue]
> lilburne <lilburne@godzilla.net> wrote:
>
>[color=green]
>>Mark McIntyre wrote:
>>
>>[color=darkred]
>>>I don't. I don't espcially care to argue about it but I'd just make
>>>the point that a tool that ostensibly is intended to help clean up
>>>your code, but which fills stdout with reams of inaccurate or
>>>misleading error messages, is worse than useless.[/color]
>>
>>lint ... | filter_out_the_error_i_dont_like[/color]
>
>
> s/error/dozens_of_errors, by which time your command line will be a
> couple of dozen screen lines long.
>[/color]

If you believe that then you are working too hard.

re: Any C/C++ LINT type checking recomendations

rlb@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<402206ab.509190738@news.individual.net>...[color=blue]
> lilburne <lilburne@godzilla.net> wrote:
>[color=green]
> > Mark McIntyre wrote:
> >[color=darkred]
> > > I don't. I don't espcially care to argue about it but I'd just make
> > > the point that a tool that ostensibly is intended to help clean up
> > > your code, but which fills stdout with reams of inaccurate or
> > > misleading error messages, is worse than useless.[/color]
> >
> > lint ... | filter_out_the_error_i_dont_like[/color]
>
> s/error/dozens_of_errors, by which time your command line will be a
> couple of dozen screen lines long.
>
> Richard[/color]

Write a script to do the filtering. You could call it
'filter_out_the_errors_i_dont_like'! Perl would be a good choice.

re: Any C/C++ LINT type checking recomendations

On 5 Feb 2004 07:33:11 -0800, in comp.lang.c ,
mysticmouflon@fsmail.net (Mystic Mouflon) wrote:
[color=blue]
>rlb@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<402206ab.509190738@news.individual.net>...[color=green]
>> lilburne <lilburne@godzilla.net> wrote:
>>[color=darkred]
>> > Mark McIntyre wrote:
>> >
>> > > I don't. I don't espcially care to argue about it but I'd just make
>> > > the point that a tool that ostensibly is intended to help clean up
>> > > your code, but which fills stdout with reams of inaccurate or
>> > > misleading error messages, is worse than useless.
>> >
>> > lint ... | filter_out_the_error_i_dont_like[/color]
>>
>> s/error/dozens_of_errors, by which time your command line will be a
>> couple of dozen screen lines long.
>>
>> Richard[/color]
>
>Write a script to do the filtering. You could call it
>'filter_out_the_errors_i_dont_like'! Perl would be a good choice.[/color]

Yeah, but then I'd have to lint the script, in case I had some bugs in
it.... :-)

Seriously tho, if I filtered it, I might filter real errors by
mistake.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---