vim7: handling sometimes unused symbols

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

vim7: handling sometimes unused symbols

Walter Briscoe
lint produces many reports like:
os_mswin.c(342) : Info 715: Symbol 'which' (line 337) not referenced

The corresponding code is:
    void
mch_restore_title(
    int which)
{
#ifndef FEAT_GUI_MSWIN
    mch_settitle((which & 1) ? g_szOrigTitle : NULL, NULL);
#endif
}

I am not comfortable about using /* ARGSUSED */ in such a context.
I would prefer something like
#else
    unused(which);

Where unused is a macro for which one definition might be
#define unused(x) (void)x
or one might use something like:
#define UNUSED(x) ( x == x )
I factor it out as a macro because different implementations are likely
to be differently picky about such tactics.
Comments? Please!
Once Bram says how he wants to handle such scenarios, I will propose
patches to fit.
--
Walter Briscoe
Reply | Threaded
Open this post in threaded view
|

Re: vim7: handling sometimes unused symbols

Bram Moolenaar

Walter Briscoe wrote:

> lint produces many reports like:
> os_mswin.c(342) : Info 715: Symbol 'which' (line 337) not referenced
>
> The corresponding code is:
>     void
> mch_restore_title(
>     int which)
> {
> #ifndef FEAT_GUI_MSWIN
>     mch_settitle((which & 1) ? g_szOrigTitle : NULL, NULL);
> #endif
> }
>
> I am not comfortable about using /* ARGSUSED */ in such a context.
> I would prefer something like
> #else
>     unused(which);
>
> Where unused is a macro for which one definition might be
> #define unused(x) (void)x
> or one might use something like:
> #define UNUSED(x) ( x == x )
> I factor it out as a macro because different implementations are likely
> to be differently picky about such tactics.
> Comments? Please!
> Once Bram says how he wants to handle such scenarios, I will propose
> patches to fit.

I normally add /*ARGSUSED*/ and don't bother to take the complicated
route.  It's not worth it.

--
The users that I support would double-click on a landmine to find out
what happens. -- A system administrator

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: vim7: handling sometimes unused symbols

Walter Briscoe
In message <[hidden email]> of Mon, 6 Jun
2005 17:15:52 in , Bram Moolenaar <[hidden email]> writes
>
>Walter Briscoe wrote:
[snip]

>> Once Bram says how he wants to handle such scenarios, I will propose
>> patches to fit.
>
>I normally add /*ARGSUSED*/ and don't bother to take the complicated
>route.  It's not worth it.

Thanks for that! I will propose patches against the next point delivery.
--
Walter Briscoe
Reply | Threaded
Open this post in threaded view
|

Re: vim7: handling sometimes unused symbols

Walter Briscoe
In message <[hidden email]> of Tue, 7 Jun
2005 06:22:12 in , Walter Briscoe <[hidden email]>
writes

>In message <[hidden email]> of Mon, 6 Jun
>2005 17:15:52 in , Bram Moolenaar <[hidden email]> writes
>>
>>Walter Briscoe wrote:
>[snip]
>
>>> Once Bram says how he wants to handle such scenarios, I will propose
>>> patches to fit.
>>
>>I normally add /*ARGSUSED*/ and don't bother to take the complicated
>>route.  It's not worth it.
>
>Thanks for that! I will propose patches against the next point delivery.
As promised! There is the odd additional thing.


--
Walter Briscoe

t.t.bz2 (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: vim7: handling sometimes unused symbols

Bram Moolenaar

Walter Briscoe wrote:

> >>> Once Bram says how he wants to handle such scenarios, I will propose
> >>> patches to fit.
> >>
> >>I normally add /*ARGSUSED*/ and don't bother to take the complicated
> >>route.  It's not worth it.
> >
> >Thanks for that! I will propose patches against the next point delivery.
>
> As promised! There is the odd additional thing.

Thanks.  I'll include most of this.

--
hundred-and-one symptoms of being an internet addict:
73. You give your dog used motherboards instead of bones

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: vim7: handling sometimes unused symbols

Walter Briscoe
In message <[hidden email]> of Fri, 10 Jun
2005 23:15:10 in , Bram Moolenaar <[hidden email]> writes

>
>Walter Briscoe wrote:
>
>> >>> Once Bram says how he wants to handle such scenarios, I will propose
>> >>> patches to fit.
>> >>
>> >>I normally add /*ARGSUSED*/ and don't bother to take the complicated
>> >>route.  It's not worth it.
>> >
>> >Thanks for that! I will propose patches against the next point delivery.
>>
>> As promised! There is the odd additional thing.
>
>Thanks.  I'll include most of this.

I look forward to it. You may also like to consider the following:

Info 754: local structure member 'room' (line 215, file eval.c) not
referenced
Info 754: local structure member 'vimvar::vv_len' (line 272, file
eval.c) not referenced
Info 754: local structure member 'vimvar::vv_filler' (line 274, file
eval.c) not referenced

The following is tricky:
ex_docmd.c(8153) : Info 715: Symbol 'prot' (line 8145) not referenced

Rather than the usual /* ARGSUSED */, I prefer:

--- src/os_amiga.h.0    Sun Jun 13 20:09:36 2004
+++ src/os_amiga.h      Sat Jun 11 15:19:14 2005
@@ -198,4 +198,4 @@
 #define mch_remove(x) remove((char *)(x))
 #define mch_rename(src, dst) rename(src, dst)
 #define mch_chdir(s) chdir(s)
-#define vim_mkdir(x, y) mch_mkdir(x)
+#define vim_mkdir(x, y) ((void)y, mch_mkdir(x))
--- src/os_msdos.h.0    Sun Jun 13 18:05:46 2004
+++ src/os_msdos.h      Sat Jun 11 15:20:00 2005
@@ -99,7 +99,7 @@
 #ifdef DJGPP
 # define vim_mkdir(x, y) mkdir((char *)(x), y)
 #else
-# define vim_mkdir(x, y) mkdir((char *)(x))
+# define vim_mkdir(x, y) ((void)y, mkdir((char *)(x)))
 #endif
 #define mch_rmdir(x) rmdir((char *)(x))

--- src/os_win32.h.0    Thu May 19 20:55:50 2005
+++ src/os_win32.h      Sat Jun 11 15:21:18 2005
@@ -184,7 +184,7 @@
 #define mch_setenv(name, val, x) setenv(name, val, x)
 #define mch_getenv(x) (char_u *)getenv((char *)(x))
 #ifdef __BORLANDC__
-# define vim_mkdir(x, y) mkdir(x)
+# define vim_mkdir(x, y) ((void)y, mkdir(x))
 #else
-# define vim_mkdir(x, y) _mkdir(x)
+# define vim_mkdir(x, y) ((void)y, _mkdir(x))
 #endif

--
Walter Briscoe
Reply | Threaded
Open this post in threaded view
|

Re: vim7: handling sometimes unused symbols

Bram Moolenaar

Walter Briscoe wrote:

> I look forward to it. You may also like to consider the following:
>
> Info 754: local structure member 'room' (line 215, file eval.c) not
> referenced

It's not referenced but the space it reserves is necessary.

> Info 754: local structure member 'vimvar::vv_len' (line 272, file
> eval.c) not referenced

That one can indeed be deleted.

> Info 754: local structure member 'vimvar::vv_filler' (line 274, file
> eval.c) not referenced

That one is used to reserve space for the name.  It's tricky...

> The following is tricky:
> ex_docmd.c(8153) : Info 715: Symbol 'prot' (line 8145) not referenced
>
> Rather than the usual /* ARGSUSED */, I prefer:

Hmm, don't see a reason to avoid ARGSUSED...

--
hundred-and-one symptoms of being an internet addict:
78. You find yourself dialing IP numbers on the phone.

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: vim7: handling sometimes unused symbols

Walter Briscoe
In message <[hidden email]> of Sat, 11 Jun
2005 20:31:37 in , Bram Moolenaar <[hidden email]> writes
>
>Walter Briscoe wrote:
[snip]

>> The following is tricky:
>> ex_docmd.c(8153) : Info 715: Symbol 'prot' (line 8145) not referenced
>>
>> Rather than the usual /* ARGSUSED */, I prefer:
>
>Hmm, don't see a reason to avoid ARGSUSED...

Whatever you prefer! ARGSUSED looks strange to me in the following:
D:\wfb\vim\bld\vim70aa\vim7\src ) sed 8140,8156!d ex_docmd.c
#if ((defined(FEAT_SESSION) || defined(FEAT_EVAL)) && defined(vim_mkdir)) \
        || defined(PROTO)
/* ARGSUSED */
    int
vim_mkdir_emsg(name, prot)
    char_u      *name;
    int         prot;
{
    if (vim_mkdir(name, prot) != 0)
    {
        EMSG2(_("E739: Cannot create directory: %s"), name);
        return FAIL;
    }
    return OK;
}
#endif


D:\wfb\vim\bld\vim70aa\vim7\src )

I suppose your counter-view is: not as strange as (void*)y.
--
Walter Briscoe
Reply | Threaded
Open this post in threaded view
|

Re: vim7: handling sometimes unused symbols

Bram Moolenaar
In reply to this post by Walter Briscoe

James Widman wrote:

> On Jun 11, 2005, at 2:31 PM, Bram Moolenaar wrote:
> > Walter Briscoe wrote:
> >> The following is tricky:
> >> ex_docmd.c(8153) : Info 715: Symbol 'prot' (line 8145) not referenced
> >>
> >> Rather than the usual /* ARGSUSED */, I prefer:
> >
> > Hmm, don't see a reason to avoid ARGSUSED...
>
> Well obviously, ARGSUSED is a wider brush, claiming that *all*  
> arguments are used, whereas Walter's preferred method would mark only  
> one named symbol as "used".  So of course some might argue that it's  
> "safer" to use that method because that way it's much harder to  
> inadvertently mark another unused  parameter as "used".  (Of course,  
> it doesn't matter in this case since  vim_mkdir_emsg() passes all of  
> its parameters on to vim_mkdir().)
>
> But Walter's method also has the potential to allow the lint user to  
> be more lazy: because both 'x' and 'y' would be marked as "used"  
> wherever vim_mkdir(x,y) is invoked, the use of that macro would never  
> introduce a need to mark the invoking function with ARGSUSED. (So if  
> there were a lot of functions that invoked vim_mkdir(x,y) with a  
> variable as the second argument, then Walter's method would require  
> fewer changes.)
>
> So in general, I think Walter's method is better, but in this case I  
> agree with you.

First of all: we are talking about lint output.  I like the output to be
"clean", but lint does tend to give warnings for things that are not
really a problem.  That happens often if you write portable code with
#ifdefs.  Or when there are problems in system header files.

In this specific case the argument is not used.  But that's OK, it should
not be used.  Thus we need to find a way to avoid the lint warning.

Actually adding code to use the variable is a wrong solution.  You
started with good code that produced a bogus warning, you end up with
wrong code that doesn't generate a warning.  If lint was smarter it
would give a warning when the argument is used in a useless way.

BTW: is there a lint for C++ code?  I currently can't lint the KDE
version.

--
hundred-and-one symptoms of being an internet addict:
80. At parties, you introduce your spouse as your "service provider."

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: vim7: handling sometimes unused symbols

Aschwin Marsman
On Sun, 12 Jun 2005, Bram Moolenaar wrote:

> BTW: is there a lint for C++ code?  I currently can't lint the KDE
> version.

I only know of commercial tools like Parasoft's Code Wizard which
appears to be incorporated in C++Test nowadays.
 
Have a nice weekend,
 
Aschwin Marsman
Reply | Threaded
Open this post in threaded view
|

Re: vim7: handling sometimes unused symbols

James Widman
In reply to this post by Bram Moolenaar

On Jun 12, 2005, at 6:26 AM, Bram Moolenaar wrote:

>
> James Widman wrote:
>
>
>> On Jun 11, 2005, at 2:31 PM, Bram Moolenaar wrote:
>>
>>> Walter Briscoe wrote:
>>>
>>>> The following is tricky:
>>>> ex_docmd.c(8153) : Info 715: Symbol 'prot' (line 8145) not  
>>>> referenced
>>>>
>>>> Rather than the usual /* ARGSUSED */, I prefer:
>>>>
>>>
>>> Hmm, don't see a reason to avoid ARGSUSED...
>>>
>>
>> Well obviously, ARGSUSED is a wider brush, claiming that *all*
>> arguments are used, whereas Walter's preferred method would mark only
>> one named symbol as "used".  So of course some might argue that it's
>> "safer" to use that method because that way it's much harder to
>> inadvertently mark another unused  parameter as "used".  (Of course,
>> it doesn't matter in this case since  vim_mkdir_emsg() passes all of
>> its parameters on to vim_mkdir().)
>>
>> But Walter's method also has the potential to allow the lint user to
>> be more lazy: because both 'x' and 'y' would be marked as "used"
>> wherever vim_mkdir(x,y) is invoked, the use of that macro would never
>> introduce a need to mark the invoking function with ARGSUSED. (So if
>> there were a lot of functions that invoked vim_mkdir(x,y) with a
>> variable as the second argument, then Walter's method would require
>> fewer changes.)
>>
>> So in general, I think Walter's method is better, but in this case I
>> agree with you.
>>
>
> First of all: we are talking about lint output.

My apologies for caring too much about Lint output. (:

> I like the output to be
> "clean", but lint does tend to give warnings for things that are not
> really a problem.

...which is why we try to provide as many ways to suppress as possible.

> That happens often if you write portable code with
> #ifdefs.  Or when there are problems in system header files.

In general, when [our] Lint parses system headers and other non-
project library headers, it should be aware that it's parsing  
"library" code, where "library" means "not your project code".  And  
there are ways to suppress messages only for library code and library  
symbols.  So it should always be possible to get zero messages about  
library code.

> In this specific case the argument is not used.  But that's OK, it  
> should
> not be used.  Thus we need to find a way to avoid the lint warning.

We do have a message suppression option called -esym (suppress some  
numbered message for some named symbol or symbol name pattern --  
e.g., -eysm(715,prot), but that's mainly appropriate for global  
symbols, since it will apply to all symbols in the program with the  
specified name.

What (I think) we'd like is the ability to suppress the message for a  
local symbol -- something like -esym(715,vim_mkdir_emsg::prot).  I  
think we've had a feature request for that before.

> Actually adding code to use the variable is a wrong solution.  You
> started with good code that produced a bogus warning, you end up with
> wrong code that doesn't generate a warning.

I guess we can't count on every compiler to elide the useless left-
hand side of the comma operator in:

#define vim_mkdir(x, y) ((void)y, mch_mkdir(x))

Some people, at some times, get around this general problem (code  
that pacifies Lint may not be the best code) by making the pacifier  
code available only to Lint; e.g.:

#ifdef _lint /* a special macro pre-defined by Lint */
#define vim_mkdir(x, y) ((void)y, mch_mkdir(x))
#else
#define vim_mkdir(x, y) mch_mkdir(x)

But of course, in this case it would be much better if we could  
simply suppress for vim_mkdir_emsg::prot.  Lacking that, the Lint  
option:
-efunc(715,vim_mkdir_emsg) or the equivalent /*ARGSUSED*/ lint  
comment appears to be the best solution.

> If lint was smarter it would give a warning when the argument is  
> used in a useless way.

Well, in general, we do.  But if you cast to void, we assume you know  
what you're doing and don't issue a message.

> BTW: is there a lint for C++ code?

Why, yes.  Yes there is.  Thank you for inviting me to plug  
shamelessly. (:

http://gimpel.com/html/products.htm
Reply | Threaded
Open this post in threaded view
|

Re: vim7: handling sometimes unused symbols

Alexei Alexandrov
In reply to this post by Bram Moolenaar
Hi Bram Moolenaar, you wrote:

>
> BTW: is there a lint for C++ code?  I currently can't lint the KDE
> version.
>

There is a toolset called FlexeLint (http://www.gimpel.com/html/products.htm). They claim to support C++ code for many Unix systems. I haven't used it myself though.

--
Alexei Alexandrov
Reply | Threaded
Open this post in threaded view
|

Re: vim7: handling sometimes unused symbols

Bram Moolenaar

Alexei Alexandrov wrote:

> > BTW: is there a lint for C++ code?  I currently can't lint the KDE
> > version.
>
> There is a toolset called FlexeLint
> (http://www.gimpel.com/html/products.htm). They claim to support C++
> code for many Unix systems. I haven't used it myself though.

It's commercial.  I don't think I will use it often enough to justify
paying money for it.  I prefer an open-source solution anyway.

--
hundred-and-one symptoms of being an internet addict:
85. Choice between paying Compuserve bill and paying for kids education
    is a no brainer -- although a bit painful for your kids.

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: vim7: handling sometimes unused symbols

Alexei Alexandrov
Hi Bram Moolenaar, you wrote:

>
> It's commercial.  I don't think I will use it often enough to justify
> paying money for it.  I prefer an open-source solution anyway.
>

Oops, sorry, I forgot to mention that. I'm very interested in free C++ lint solution as well and I'd been seeking it around but those pay-for-me tools were the only I managed to find.

I would really appreciate if anyone point me at free C++ lint, too.

--
Alexei Alexandrov
Reply | Threaded
Open this post in threaded view
|

Re: vim7: handling sometimes unused symbols

Walter Briscoe
In reply to this post by Bram Moolenaar
In message <[hidden email]> of Sun, 12 Jun
2005 23:44:34 in , Bram Moolenaar <[hidden email]> writes

>
>Alexei Alexandrov wrote:
>
>> > BTW: is there a lint for C++ code?  I currently can't lint the KDE
>> > version.
>>
>> There is a toolset called FlexeLint
>> (http://www.gimpel.com/html/products.htm). They claim to support C++
>> code for many Unix systems. I haven't used it myself though.
>
>It's commercial.  I don't think I will use it often enough to justify
>paying money for it.  I prefer an open-source solution anyway.
>

PC-lint and FlexeLint are approximately the same tool.
PC-lint is a regular windows application and AFAIR costs about 250USD.
FlexeLint is delivered as "obfuscated" C and AFAIR costs from about
1000USD. It has an interface module which allows a fair amount of
tailoring. ISTR, it had a money-back 30 day guarantee.

[ I did not get James Widman's first post. It was not retained as spam
by my ISP. I know about it because one of your messages has this header:
In-Reply-To: <[hidden email]>
How do I request it from ezmlm? ]

Quietening compilers (I classify lint as a compiler) is an art.
Your point that (void)foo will not necessarily quieten a particular
compiler is well taken. That is why I prefer UNUSED(foo) where UNUSED
has a definition tailored for a compiler. As I think ARGSUSED is too
broad and the narrower controls offered by PC/Flexelint were not
available to me, I used (void)y to deal with the peculiarities of mkdir.
I accept it may not be the best solution.

PC/FlexeLint is a mature product with a low rate of development.
It is solid on some points and flaky on others - particularly flow-
control analysis. e.g. it produces
        return bar;
                  ^
bar.c(17) : Warning 644: Variable 'bar' (line 9) may not have been initialized

given:
/* PC-lint does not understand flag variables */

int foo(int arg);

    int
foo(arg)
int arg;
{
    int bar;
    int set;

    if (arg)
        bar = 42, set = 1;
    else
        set = 0;
    if (set)
        return bar;
    else
        return 0;
}

Diagnostics point to characters within lines - and expand macros if
necessary. I spent several clients' money on FlexeLint and my own on PC-
lint. I now have a free copy as a tester. When I first bought it, it
roughly doubled the rate at which I could produce deliverable code.
( That may say I am a crap coder ;)

It eliminated 99% of uninitialized variables, and printf and scanf call
errors. These are NOW less problematic because gcc is effective in
identifying many of them. OTOH, PC-lint allows you to specify
sizeof(int) as 2 or whatever other value suits.
More than once, I have found a bug in somebody else's code within an
hour which they had failed to find in two days.

Bram uses several macros which evaluate their parameters more than once
in vim. These are potentially problematic when called with values with
side-effects. PC-lint identifies those potential problems and I flagged
them to Bram. He accepted most of what I proposed on them.

For vim, I have PC-lint set at a low level. I switch on 2 classes of
data equivalence and off 83 diagnostics which are on in my default
filter. I start being VERY picky. That filter leads me to code in
particular ways. I don't want to bore further with detail.

I sympathise with Bram's decision not to use it as a commercial product.
I failed to get anything from lclint/splint which is open-source but
does not support C++. I looked at products costing more than 10 times as
much as PC-lint but they were not cost-effective to me. YMMV.

I have a lot of diagnostics from PC-lint at that low level on if_ole.cpp
I will post them to Bram to give a flavour of what is available.
--
Walter Briscoe
Reply | Threaded
Open this post in threaded view
|

Re: vim7: handling sometimes unused symbols

Nikolai Weibull
Walter Briscoe wrote:

[lint discussion]

Sorry to barge in, but what lint, if any, are you using Bram?  There???s
always splint (http://www.splint.org/), which is horribly configurable,
        nikolai

--
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
Reply | Threaded
Open this post in threaded view
|

Re: vim7: handling sometimes unused symbols

Bram Moolenaar

Nikolai Weibull wrote:

> Walter Briscoe wrote:
>
> [lint discussion]
>
> Sorry to barge in, but what lint, if any, are you using Bram?
> There???s always splint (http://www.splint.org/), which is
> horribly configurable,

Splint doesn't support C++ either.

My lint is what comes with FreeBSD.  It doesn't mention a version name
or number and doesn't support "--version"...

--
From "know your smileys":
 ;-0 Can't find shift key
 ,-9 Kann Umschalttaste nicht finden

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: vim7: handling sometimes unused symbols

James Widman
In reply to this post by Walter Briscoe

On Jun 13, 2005, at 9:45 AM, Walter Briscoe wrote:

> In message <[hidden email]> of Sun, 12 Jun
> 2005 23:44:34 in , Bram Moolenaar <[hidden email]> writes
>
>>
>> Alexei Alexandrov wrote:
>>
>>
>>>> BTW: is there a lint for C++ code?  I currently can't lint the KDE
>>>> version.
>>>>
>>>
>>> There is a toolset called FlexeLint
>>> (http://www.gimpel.com/html/products.htm). They claim to support C++
>>> code for many Unix systems. I haven't used it myself though.
>>>
>>
>> It's commercial.  I don't think I will use it often enough to justify
>> paying money for it.  I prefer an open-source solution anyway.
>>
>>
>
> PC-lint and FlexeLint are approximately the same tool.
> PC-lint is a regular windows application and AFAIR costs about 250USD.
> FlexeLint is delivered as "obfuscated" C and AFAIR costs from about
> 1000USD.

This is getting terribly off-topic, but actual prices are at:
http://gimpel.com/html/order.htm

> It has an interface module which allows a fair amount of
> tailoring. ISTR, it had a money-back 30 day guarantee.

Correct.

> [ I did not get James Widman's first post. It was not retained as spam
> by my ISP. I know about it because one of your messages has this  
> header:
> In-Reply-To: <[hidden email]>
> How do I request it from ezmlm? ]

Apologies:  I made the mistake of posting before subscribing.  
However, Bram's reply included the complete text of my first  
attempted post.

> Quietening compilers (I classify lint as a compiler) is an art.
> Your point that (void)foo will not necessarily quieten a particular
> compiler is well taken. That is why I prefer UNUSED(foo) where UNUSED
> has a definition tailored for a compiler. As I think ARGSUSED is too
> broad and the narrower controls offered by PC/Flexelint were not
> available to me, I used (void)y to deal with the peculiarities of  
> mkdir.
> I accept it may not be the best solution.
>
> PC/FlexeLint is a mature product with a low rate of development.
> It is solid on some points and flaky on others - particularly flow-
> control analysis. e.g. it produces
>         return bar;
>                   ^
> bar.c(17) : Warning 644: Variable 'bar' (line 9) may not have been  
> initialized

[Apologies again for getting off-topic]

This is because making the value-tracking system aware of  
correlations between ranges of values of expressions (in this case  
between 'set' and 'bar') turns out to be somewhat non-trivial in the  
general case.  But we hope to address this issue in the future.

That said, even in situations like the example below, it's probably  
best not to dismiss and suppress the diagnostic outright:  the mere  
existence of such correlations should tell you that the code is very  
possibly brittle.  Suppose that at some point in the future of  
project development, the first 'else' branch initializes 'set' with a  
function call instead of the integer literal 0.  In a larger, more  
complex version of 'foo', the danger of returning an uninitialized  
'bar' would become less obvious to the person reading the code.  It's  
been our observation that normally, such code can be re-written so  
that there is no such correlation; this tends to make the code more  
malleable.  It also introduces the side benefit (which, admittedly,  
is dubious to some) of quieting Lint without a suppression.

> given:
> /* PC-lint does not understand flag variables */
>
> int foo(int arg);
>
>     int
> foo(arg)
> int arg;
> {
>     int bar;
>     int set;
>
>     if (arg)
>         bar = 42, set = 1;
>     else
>         set = 0;
>     if (set)
>         return bar;
>     else
>         return 0;
> }

James Widman
--
Gimpel Software
http://gimpel.com