Loading ...
Sorry, an error occurred while loading the content.
 

Re: vim7: handling sometimes unused symbols

Expand Messages
  • Walter Briscoe
    In message of Mon, 6 Jun 2005 17:15:52 in , Bram Moolenaar writes ... [snip] ... Thanks for
    Message 1 of 18 , Jun 6, 2005
      In message <200506061515.j56FFq0U014593@...> of Mon, 6 Jun
      2005 17:15:52 in , Bram Moolenaar <Bram@...> 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
    • Walter Briscoe
      In message of Tue, 7 Jun 2005 06:22:12 in , Walter Briscoe writes ... As
      Message 2 of 18 , Jun 10, 2005
        In message <ZLNUuWDU0TpCFwJB@...> of Tue, 7 Jun
        2005 06:22:12 in , Walter Briscoe <wbriscoe@...>
        writes
        >In message <200506061515.j56FFq0U014593@...> of Mon, 6 Jun
        >2005 17:15:52 in , Bram Moolenaar <Bram@...> 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.
      • Bram Moolenaar
        ... 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 ///
        Message 3 of 18 , Jun 10, 2005
          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 -- Bram@... -- 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 ///
        • Walter Briscoe
          In message of Fri, 10 Jun 2005 23:15:10 in , Bram Moolenaar writes ... I look forward to it.
          Message 4 of 18 , Jun 11, 2005
            In message <200506102115.j5ALFAre064140@...> of Fri, 10 Jun
            2005 23:15:10 in , Bram Moolenaar <Bram@...> 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
          • Bram Moolenaar
            ... It s not referenced but the space it reserves is necessary. ... That one can indeed be deleted. ... That one is used to reserve space for the name. It s
            Message 5 of 18 , Jun 11, 2005
              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 -- Bram@... -- 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 ///
            • Walter Briscoe
              In message of Sat, 11 Jun 2005 20:31:37 in , Bram Moolenaar writes ... [snip] ... Whatever you
              Message 6 of 18 , Jun 11, 2005
                In message <200506111831.j5BIVbjD002926@...> of Sat, 11 Jun
                2005 20:31:37 in , Bram Moolenaar <Bram@...> 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
              • Bram Moolenaar
                ... 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
                Message 7 of 18 , Jun 12, 2005
                  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 -- Bram@... -- 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 ///
                • Aschwin Marsman
                  ... 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
                  Message 8 of 18 , Jun 12, 2005
                    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
                  • James Widman
                    ... 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
                    Message 9 of 18 , Jun 12, 2005
                      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
                    • Alexei Alexandrov
                      ... 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
                      Message 10 of 18 , Jun 12, 2005
                        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
                      • Bram Moolenaar
                        ... 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
                        Message 11 of 18 , Jun 12, 2005
                          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 -- Bram@... -- 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 ///
                        • Alexei Alexandrov
                          ... 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
                          Message 12 of 18 , Jun 12, 2005
                            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
                          • Walter Briscoe
                            In message of Sun, 12 Jun 2005 23:44:34 in , Bram Moolenaar writes ... PC-lint and FlexeLint
                            Message 13 of 18 , Jun 13, 2005
                              In message <200506122144.j5CLiYDC085907@...> of Sun, 12 Jun
                              2005 23:44:34 in , Bram Moolenaar <Bram@...> 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: <9651A0B2-0EB3-4D5B-BFDD-DB9ED57BB666@...>
                              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
                            • 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
                              Message 14 of 18 , Jun 13, 2005
                                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);}
                              • Bram Moolenaar
                                ... 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 ... --
                                Message 15 of 18 , Jun 13, 2005
                                  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 -- Bram@... -- 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 ///
                                • James Widman
                                  ... This is getting terribly off-topic, but actual prices are at: http://gimpel.com/html/order.htm ... Correct. ... Apologies: I made the mistake of posting
                                  Message 16 of 18 , Jun 14, 2005
                                    On Jun 13, 2005, at 9:45 AM, Walter Briscoe wrote:

                                    > In message <200506122144.j5CLiYDC085907@...> of Sun, 12 Jun
                                    > 2005 23:44:34 in , Bram Moolenaar <Bram@...> 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: <9651A0B2-0EB3-4D5B-BFDD-DB9ED57BB666@...>
                                    > 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
                                  Your message has been successfully submitted and would be delivered to recipients shortly.