Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.programmer > #1071 > unrolled thread

C Code "sanity checking" tools

Back to article view | Back to comp.unix.programmer

Contents

  C Code "sanity checking" tools Martin Crouch <spamspamspam@spaml.com> - 2011-08-08 12:00 +0100
    Re: C Code "sanity checking" tools Richard Kettlewell <rjk@greenend.org.uk> - 2011-08-08 12:09 +0100
      Re: C Code "sanity checking" tools Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net> - 2011-08-09 08:50 +0200
        Re: C Code "sanity checking" tools Måns Rullgård <mans@mansr.com> - 2011-08-09 10:55 +0100
          Re: C Code "sanity checking" tools Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-09 14:15 +0100
          Re: C Code "sanity checking" tools Nomen Nescio <nobody@dizum.com> - 2011-08-10 01:58 +0200
          Re: C Code "sanity checking" tools Nomen Nescio <nobody@dizum.com> - 2011-08-10 12:29 +0200
        Re: C Code "sanity checking" tools Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-09 14:17 +0100
          Re: C Code "sanity checking" tools Keith Thompson <kst-u@mib.org> - 2011-08-09 09:17 -0700
            Re: C Code "sanity checking" tools Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-09 17:36 +0100
              Re: C Code "sanity checking" tools Keith Thompson <kst-u@mib.org> - 2011-08-09 12:19 -0700
                Re: C Code "sanity checking" tools Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-09 20:36 +0100
                  Re: C Code "sanity checking" tools Michael Press <rubrum@pacbell.net> - 2011-08-09 19:24 -0700
                    Re: C Code "sanity checking" tools Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-10 10:27 +0100
                      Re: C Code "sanity checking" tools Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-10 14:01 +0100
                        Re: C Code "sanity checking" tools "io_x" <a@b.c.invalid> - 2011-08-13 09:42 +0200
                        Re: C Code "sanity checking" tools Keith Thompson <kst-u@mib.org> - 2011-08-13 16:04 -0700
                          Re: C Code "sanity checking" tools Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-14 19:46 +0100
    Re: C Code "sanity checking" tools Ian Collins <ian-news@hotmail.com> - 2011-08-08 23:12 +1200
      Re: C Code "sanity checking" tools Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-08 15:35 +0100
        Re: C Code "sanity checking" tools Martin Crouch <spamspamspam@spaml.com> - 2011-08-08 16:05 +0100
          Re: C Code "sanity checking" tools Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-08 22:57 +0100
            Re: C Code "sanity checking" tools Måns Rullgård <mans@mansr.com> - 2011-08-08 23:32 +0100
        Re: C Code "sanity checking" tools Ian Collins <ian-news@hotmail.com> - 2011-08-09 08:03 +1200
          Re: C Code "sanity checking" tools Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-08 22:51 +0100
            Re: C Code "sanity checking" tools Ian Collins <ian-news@hotmail.com> - 2011-08-09 10:01 +1200
      Re: C Code "sanity checking" tools jt@toerring.de (Jens Thoms Toerring) - 2011-08-08 22:06 +0000
        Re: C Code "sanity checking" tools Ian Collins <ian-news@hotmail.com> - 2011-08-09 10:18 +1200
          Re: C Code "sanity checking" tools jt@toerring.de (Jens Thoms Toerring) - 2011-08-08 23:25 +0000
    Re: C Code "sanity checking" tools Nobody <nobody@nowhere.com> - 2011-08-08 14:01 +0100
      Re: C Code "sanity checking" tools Måns Rullgård <mans@mansr.com> - 2011-08-08 14:47 +0100
        Re: C Code "sanity checking" tools Martin Crouch <spamspamspam@spaml.com> - 2011-08-08 16:08 +0100
          Re: C Code "sanity checking" tools Marc <marc.glisse@gmail.com> - 2011-08-08 15:39 +0000
        Re: C Code "sanity checking" tools William Ahern <william@wilbur.25thandClement.com> - 2011-08-08 10:20 -0700
        Re: C Code "sanity checking" tools Nobody <nobody@nowhere.com> - 2011-08-09 00:59 +0100
    Re: C Code "sanity checking" tools mathog <dmathog@gmail.com> - 2011-08-08 08:48 -0700

Page 2 of 2 — ← Prev page 1 [2]

#1077

> I don't think unit tests should be the first line of defence here.  It's
> too common to find a forgiving environment where, say, an uninitialised
> string happens to be a null string, or where a buffer overrun is silent.
>

That's right, the code we actually had a problem with passed system 
testing, user acceptance testing and had been running live for a couple 
of years without a problem being noticed.  It just happened to get 
garbage in the wrong part of memory so the string wasn't empty this time 
and it went pop.

[toc] | [prev] | [next] | [standalone]

#1084

Martin Crouch <spamspamspam@spaml.com> writes:

[Please include attributions (like the line above) in your posts.]

>> I don't think unit tests should be the first line of defence here.  It's
>> too common to find a forgiving environment where, say, an uninitialised
>> string happens to be a null string, or where a buffer overrun is silent.
>>
>
> That's right, the code we actually had a problem with passed system
> testing, user acceptance testing and had been running live for a
> couple of years without a problem being noticed.  It just happened to
> get garbage in the wrong part of memory so the string wasn't empty
> this time and it went pop.

Someone has already pointed out valgrind so I'll just second that.  In
addition, I've had some good help from splint[1]:

  $ splint printf.c
  Splint 3.1.2 --- 03 May 2009
   
  printf.c: (in function main)
  printf.c:6:23: Passed storage mystring not completely defined (*mystring is
                    undefined): printf (..., mystring, ...)
    Storage derivable from a parameter, return value or global is not defined.
    Use /*@out@*/ to denote passed or returned storage which need not be defined.
    (Use -compdef to inhibit warning)
   
  Finished checking --- 1 code warning

It's default setting don't seem to suit my coding style, but it's highly
configurable so I may continue to use it.  Unfortunately, it results is
lots of split-specific comments to control the output.

[1] <http://www.splint.org>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#1088

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Martin Crouch <spamspamspam@spaml.com> writes:
>
> [Please include attributions (like the line above) in your posts.]
>
>>> I don't think unit tests should be the first line of defence here.  It's
>>> too common to find a forgiving environment where, say, an uninitialised
>>> string happens to be a null string, or where a buffer overrun is silent.
>>>
>>
>> That's right, the code we actually had a problem with passed system
>> testing, user acceptance testing and had been running live for a
>> couple of years without a problem being noticed.  It just happened to
>> get garbage in the wrong part of memory so the string wasn't empty
>> this time and it went pop.
>
> Someone has already pointed out valgrind so I'll just second that.  In
> addition, I've had some good help from splint[1]:
>
>   $ splint printf.c
>   Splint 3.1.2 --- 03 May 2009
>
>   printf.c: (in function main)
>   printf.c:6:23: Passed storage mystring not completely defined (*mystring is
>                     undefined): printf (..., mystring, ...)
>     Storage derivable from a parameter, return value or global is not defined.
>     Use /*@out@*/ to denote passed or returned storage which need not be defined.
>     (Use -compdef to inhibit warning)
>
>   Finished checking --- 1 code warning

IIRC splint will give some error even if you do initialise the array.
It simply has a ridiculous notion of how pointers to should be passed
around.

-- 
Måns Rullgård
mans@mansr.com

[toc] | [prev] | [next] | [standalone]

#1082

On 08/ 9/11 02:35 AM, Ben Bacarisse wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>
>> On 08/ 8/11 11:00 PM, Martin Crouch wrote:
>
>>> If I write some code like this:
>>>
>>> #include<stdio.h>
>>> int main(void)
>>> {
>>>     char mystring[5];
>>>
>>>     printf("String:%s\n",mystring);
>>>
>>>     return 0;
>>> }
>>>
>>> It compiles okay (no warnings),  but when runs it has undefined results
>>> because I've not put anything into mystring before attempting to print
>>> it, so it gets whatever garbage is left in memory.
>>>
>>> Are there any "pre-compiler" code analysis tools out there that would
>>> pick up this sort of problem?  The platform is sparc Solaris 10.
>>
>> Unit tests (written first).
>
> I don't think unit tests should be the first line of defence here.  It's
> too common to find a forgiving environment where, say, an uninitialised
> string happens to be a null string, or where a buffer overrun is silent.

My point was if the code was written to pass a test, the bug probably 
wouldn't have been introduced in the first place.

As the answers here show, this kind of problem is a difficult one for 
compilers and lint to pick up.  None that I know will spot this.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#1083

Ian Collins <ian-news@hotmail.com> writes:

> On 08/ 9/11 02:35 AM, Ben Bacarisse wrote:
>> Ian Collins<ian-news@hotmail.com>  writes:
>>
>>> On 08/ 8/11 11:00 PM, Martin Crouch wrote:
>>
>>>> If I write some code like this:
>>>>
>>>> #include<stdio.h>
>>>> int main(void)
>>>> {
>>>>     char mystring[5];
>>>>
>>>>     printf("String:%s\n",mystring);
>>>>
>>>>     return 0;
>>>> }
>>>>
>>>> It compiles okay (no warnings),  but when runs it has undefined results
>>>> because I've not put anything into mystring before attempting to print
>>>> it, so it gets whatever garbage is left in memory.
>>>>
>>>> Are there any "pre-compiler" code analysis tools out there that would
>>>> pick up this sort of problem?  The platform is sparc Solaris 10.
>>>
>>> Unit tests (written first).
>>
>> I don't think unit tests should be the first line of defence here.  It's
>> too common to find a forgiving environment where, say, an uninitialised
>> string happens to be a null string, or where a buffer overrun is silent.
>
> My point was if the code was written to pass a test, the bug probably
> wouldn't have been introduced in the first place.

Yes, I got that that was your point!  Did you get that I was disagreeing
with it? :-)

We may have to leave it there since we are both making statistical
arguments: you say that units test will "probably" prevent the bug
appearing, and I am saying that cases where it might not are all "too
common".  I have no data to back up my statistics except anecdotes to
the effect that it's happened more than once.

> As the answers here show, this kind of problem is a difficult one for
> compilers and lint to pick up.  None that I know will spot this.

Unit tests + valgrind would be my proposal:

  $ gcc -g -o printf -std=c99 -pedantic -Wall -Wextra printf.c
  $ valgrind ./printf
  ==16796== Memcheck, a memory error detector
  ==16796== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
  ==16796== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
  ==16796== Command: ./printf
  ==16796== 
  ==16796== Conditional jump or move depends on uninitialised value(s)
  ==16796==    at 0x4E7635E: vfprintf (vfprintf.c:1614)
  ==16796==    by 0x4E7D539: printf (printf.c:35)
  ==16796==    by 0x400544: main (printf.c:6)
  ==16796== 
  ... etc...

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#1085

On 08/ 9/11 09:51 AM, Ben Bacarisse wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>
>> On 08/ 9/11 02:35 AM, Ben Bacarisse wrote:
>>> Ian Collins<ian-news@hotmail.com>   writes:
>>>
>>>> On 08/ 8/11 11:00 PM, Martin Crouch wrote:
>>>
>>>>> If I write some code like this:
>>>>>
>>>>> #include<stdio.h>
>>>>> int main(void)
>>>>> {
>>>>>      char mystring[5];
>>>>>
>>>>>      printf("String:%s\n",mystring);
>>>>>
>>>>>      return 0;
>>>>> }
>>>>>
>>>>> It compiles okay (no warnings),  but when runs it has undefined results
>>>>> because I've not put anything into mystring before attempting to print
>>>>> it, so it gets whatever garbage is left in memory.
>>>>>
>>>>> Are there any "pre-compiler" code analysis tools out there that would
>>>>> pick up this sort of problem?  The platform is sparc Solaris 10.
>>>>
>>>> Unit tests (written first).
>>>
>>> I don't think unit tests should be the first line of defence here.  It's
>>> too common to find a forgiving environment where, say, an uninitialised
>>> string happens to be a null string, or where a buffer overrun is silent.
>>
>> My point was if the code was written to pass a test, the bug probably
>> wouldn't have been introduced in the first place.
>
> Yes, I got that that was your point!  Did you get that I was disagreeing
> with it? :-)

I do and I agree tests aren't a panacea.  I reorder my tests fairly 
often to help with detecting code that accidentally relies on 
uninitialised memory.  It is easy to test for reading uninitialised 
dynamic memory, but much harder with automatic variables.

> We may have to leave it there since we are both making statistical
> arguments: you say that units test will "probably" prevent the bug
> appearing, and I am saying that cases where it might not are all "too
> common".  I have no data to back up my statistics except anecdotes to
> the effect that it's happened more than once.
>
>> As the answers here show, this kind of problem is a difficult one for
>> compilers and lint to pick up.  None that I know will spot this.
>
> Unit tests + valgrind would be my proposal:
>
>    $ gcc -g -o printf -std=c99 -pedantic -Wall -Wextra printf.c
>    $ valgrind ./printf
>    ==16796== Memcheck, a memory error detector
>    ==16796== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
>    ==16796== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
>    ==16796== Command: ./printf
>    ==16796==
>    ==16796== Conditional jump or move depends on uninitialised value(s)
>    ==16796==    at 0x4E7635E: vfprintf (vfprintf.c:1614)
>    ==16796==    by 0x4E7D539: printf (printf.c:35)
>    ==16796==    by 0x400544: main (printf.c:6)
>    ==16796==
>    ... etc...

I certainly agree with that, I do much the same by running tests under 
dbx with memory checking enabled.

But which is the first line of defence, the tests or valgrind?

:)

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#1086

Ian Collins <ian-news@hotmail.com> wrote:
> On 08/ 8/11 11:00 PM, Martin Crouch wrote:
> > Hi,
> >
> > If I write some code like this:
> >
> > #include<stdio.h>
> > int main(void)
> > {
> >    char mystring[5];
> >
> >    printf("String:%s\n",mystring);
> >
> >    return 0;
> > }
> >
> > It compiles okay (no warnings),  but when runs it has undefined results
> > because I've not put anything into mystring before attempting to print
> > it, so it gets whatever garbage is left in memory.
> >
> > Are there any "pre-compiler" code analysis tools out there that would
> > pick up this sort of problem?  The platform is sparc Solaris 10.

> Unit tests (written first).

While I tend to agree with Ben that this may not be one of
the most obvious examples for the usefulness of unit tests I
have a quite different question: I haven't gotten into the
habit of writing unit tests and actually have to admit that
I don't have much more than a rather fuzzy idea what it might
involve. On the other hand I'd rather like to learn a bit more
about this concept. Is there something you could recommend
(going a bit further than e.g. Wikipedia) for reading to get
me started (in the best of all cases not too much tied to a
single language)?
                      Thanks and best regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#1087

On 08/ 9/11 10:06 AM, Jens Thoms Toerring wrote:
>
> While I tend to agree with Ben that this may not be one of
> the most obvious examples for the usefulness of unit tests I
> have a quite different question: I haven't gotten into the
> habit of writing unit tests and actually have to admit that
> I don't have much more than a rather fuzzy idea what it might
> involve. On the other hand I'd rather like to learn a bit more
> about this concept. Is there something you could recommend
> (going a bit further than e.g. Wikipedia) for reading to get
> me started (in the best of all cases not too much tied to a
> single language)?

The C2 wiki is the original and probably still the best place to start.

http://c2.com/cgi/wiki?UnitTest

http://c2.com/cgi/wiki?CodeUnitTestFirst

There are <pick your language>Unit test frameworks for just about every 
common language.  The original was jUnit which is integrated into just 
about every Java IDE.  I use cppUnit for C and C++ and phpUnit for (you 
guessed it..) PHP.  Both integrate well into my IDE of choice 
(NetBeans).  jsUnit is an excellent testing tool for JavaScript.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#1089

Ian Collins <ian-news@hotmail.com> wrote:
> On 08/ 9/11 10:06 AM, Jens Thoms Toerring wrote:
> >
> > While I tend to agree with Ben that this may not be one of
> > the most obvious examples for the usefulness of unit tests I
> > have a quite different question: I haven't gotten into the
> > habit of writing unit tests and actually have to admit that
> > I don't have much more than a rather fuzzy idea what it might
> > involve. On the other hand I'd rather like to learn a bit more
> > about this concept. Is there something you could recommend
> > (going a bit further than e.g. Wikipedia) for reading to get
> > me started (in the best of all cases not too much tied to a
> > single language)?

> The C2 wiki is the original and probably still the best place to start.

> http://c2.com/cgi/wiki?UnitTest

> http://c2.com/cgi/wiki?CodeUnitTestFirst

> There are <pick your language>Unit test frameworks for just about every 
> common language.  The original was jUnit which is integrated into just 
> about every Java IDE.  I use cppUnit for C and C++ and phpUnit for (you 
> guessed it..) PHP.  Both integrate well into my IDE of choice 
> (NetBeans).  jsUnit is an excellent testing tool for JavaScript.

Thank you, I guess I will spend some time in the next days
reading and playing around with things;-)

                            Best regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#1074

On Mon, 08 Aug 2011 12:00:11 +0100, Martin Crouch wrote:

> If I write some code like this:
> 
> #include <stdio.h>
> int main(void)
> {
>   char mystring[5];
> 
>   printf("String:%s\n",mystring);
> 
>   return 0;
> }
> }
> It compiles okay (no warnings),

Really? You should get an error due to the extra closing brace.

> but when runs it has undefined results
> because I've not put anything into mystring before attempting to print it,
> so it gets whatever garbage is left in memory.
> 
> Are there any "pre-compiler" code analysis tools out there that would pick
> up this sort of problem?  The platform is sparc Solaris 10.

In general, "gcc -O -Wall ..." will warn about using uninitialised
variables. It won't work in the specific case above because gcc doesn't
know that the printf() call will access the elements of mystring. If the
format string had "%p" instead of "%s":

	printf("String:%p\n",mystring);

there wouldn't actually be any error in the code. OTOH, this:

	printf("String:%c\n",mystring[0]);

will result in a warning (with "-O -Wall") because it can see the access.

Similarly, this:

	scanf("String:%s\n",mystring);

doesn't have any issues, because the array is written rather than read.

Note that printf() is a harder case because it's variadic; otherwise, it
would be reasonable to assume that an array passed as a "const char *"
argument is going to be read and should contain something (there are cases
where this needn't be true, e.g. the "%p" example, but any static analysis
tool is going to give the occasional false result).

[toc] | [prev] | [next] | [standalone]

#1075

Nobody <nobody@nowhere.com> writes:

> On Mon, 08 Aug 2011 12:00:11 +0100, Martin Crouch wrote:
>
>> If I write some code like this:
>> 
>> #include <stdio.h>
>> int main(void)
>> {
>>   char mystring[5];
>> 
>>   printf("String:%s\n",mystring);
>> 
>>   return 0;
>> }
>> }
>> It compiles okay (no warnings),
>
> Really? You should get an error due to the extra closing brace.
>
>> but when runs it has undefined results
>> because I've not put anything into mystring before attempting to print it,
>> so it gets whatever garbage is left in memory.
>> 
>> Are there any "pre-compiler" code analysis tools out there that would pick
>> up this sort of problem?  The platform is sparc Solaris 10.
>
> In general, "gcc -O -Wall ..." will warn about using uninitialised
> variables. It won't work in the specific case above because gcc doesn't
> know that the printf() call will access the elements of mystring.

Actually, many compilers, gcc included, parse printf format strings and
verify the arguments are compatible.

-- 
Måns Rullgård
mans@mansr.com

[toc] | [prev] | [next] | [standalone]

#1078

>> In general, "gcc -O -Wall ..." will warn about using uninitialised
>> variables. It won't work in the specific case above because gcc doesn't
>> know that the printf() call will access the elements of mystring.
>
> Actually, many compilers, gcc included, parse printf format strings and
> verify the arguments are compatible.
>

We're still using the SUNWspro "cc" compiler  maybe I'll get an install 
of gcc and see what it throws up. Thanks.

[toc] | [prev] | [next] | [standalone]

#1079

Martin Crouch  wrote:

>>> In general, "gcc -O -Wall ..." will warn about using uninitialised
>>> variables. It won't work in the specific case above because gcc doesn't
>>> know that the printf() call will access the elements of mystring.
>>
>> Actually, many compilers, gcc included, parse printf format strings and
>> verify the arguments are compatible.
> 
> We're still using the SUNWspro "cc" compiler  maybe I'll get an install 
> of gcc and see what it throws up. Thanks.

lint (comes with SUNWspro) also parses printf format. For the
particular example posted here, it doesn't complain (well, just about
the unused return value from printf), but then neither do other
compilers.

[toc] | [prev] | [next] | [standalone]

#1081

Måns Rullgård <mans@mansr.com> wrote:
> Nobody <nobody@nowhere.com> writes:
<snip>
> > In general, "gcc -O -Wall ..." will warn about using uninitialised
> > variables. It won't work in the specific case above because gcc doesn't
> > know that the printf() call will access the elements of mystring.
>
> Actually, many compilers, gcc included, parse printf format strings and
> verify the arguments are compatible.

The argument types, sure. But I'd bet that the printf bits of GCC are
completely distinct and separate from the data flow analysis bits that can
catch uninitialized _access_.

Issues like this cry out for a patch (likely non-trivial, unless the ground
work has already been laid for routines like memcpy), but the last time I
tried to grok the printf checking code in GCC it took me several weeks to
recuperate. clang doesn't catch it either, but that's another kind of
headache of similar magnitude.

[toc] | [prev] | [next] | [standalone]

#1090

On Mon, 08 Aug 2011 14:47:48 +0100, Måns Rullgård wrote:

>> In general, "gcc -O -Wall ..." will warn about using uninitialised
>> variables. It won't work in the specific case above because gcc doesn't
>> know that the printf() call will access the elements of mystring.
> 
> Actually, many compilers, gcc included, parse printf format strings and
> verify the arguments are compatible.

That isn't relevant to the part you quoted (it /is/ relevant to the
issue of printf() being variadic, which I mentioned at the end).

Type information alone isn't sufficient to accurately determine behaviour
(although it might be a useful heuristic). In spite of knowing the
argument types, gcc won't complain about this either:

#include <stdio.h>
#include <string.h>
int main(void)
{
  char mystring[5];

  printf("Length:%d\n",strlen(mystring));

  return 0;
}

A heuristic-based analyser might infer that passing a "const" pointer to
uninitialised data is probably an error, although it's not certain.
Ultimately, you can't know for sure without knowing the workings of the
library function.

[toc] | [prev] | [next] | [standalone]

#1080

Martin Crouch wrote:

> #include <stdio.h>
> int main(void)
> {
> char mystring[5];
>
> printf("String:%s\n",mystring);
>
> return 0;
> }
>
> It compiles okay (no warnings), but when runs it has undefined results
> because I've not put anything into mystring before attempting to print
> it, so it gets whatever garbage is left in memory.

While it is definitely not a pre-analysis tool, valgrind will usually 
catch this type of error, along with numerous other types of memory 
access and allocation problems.  Valgrind can't perform miracles though. 
  For instance, it can't tell if code is reading from the wrong elements 
in an array when all array elements have previously been initialized and 
all the reads fall within the array.

Regards,

David Mathog

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.unix.programmer

csiph-web