Static or dynamic code analysis software

2012-01-16 Thread Chris Smith
Hi,

Are there any dynamic or static C code analysis tools available for
OpenBSD? I've historically used valgrind on Linux and whilst I know it
is not compatible with OpenBSD, I'd still like to be able to check that
I've not made any hideous cock-ups in my code.

A few minutes of poking around the Internet returned nothing useful
unfortunately.

Best Regards,

Chris Smith



Re: Static or dynamic code analysis software

2012-01-16 Thread Norman Golisz
Hi Chris,

On Mon Jan 16 2012 12:21, Chris Smith wrote:
 Are there any dynamic or static C code analysis tools available for
 OpenBSD?

there has been a thread around here [1]. Examples include lint,
cppcheck, clang's static analyser and parfait.

Yours,
Norman

[1] http://comments.gmane.org/gmane.os.openbsd.misc/192303



Re: Static or dynamic code analysis software

2012-01-16 Thread Steffen Daode Nurpmeso
Chris Smith wrote [2012-01-16 13:21+0100]:
 Are there any dynamic or static C code analysis tools available for
 OpenBSD? [swoosh]

You may try llvm from packages, it aims to have a good analyzer.
lint(1) is in base.

 I'd still like to be able to check that I've not made any
 hideous cock-ups in my code.

You may do manual code adjustments, as in

ret
fun(args)
{
var;
nyd_enter;

[non_crashing_]asserts[_jumps];

[nyd wherever]

jleave:
nyd_leave;
return;
}

and then define the nyd_* series to something useful (not-yet-dead
peeps or collection of profiling info, as desired).
This works for many years quite well for me (userland).

 A few minutes of poking around the Internet returned nothing useful
 unfortunately.

Well, if you're running Xorg(1), xeyes(1) may help you to do the
job if you're happily distracted (due to whatever reasons).

 Best Regards,

Otherwise the usual rules may help you:
- make functions as small as possible (much less than a screenful
  of lines),
- place useful comments in the code,
- implement tests for all possible and impossible usage cases
  (easily possible with non-crashing assertions)
- ask yourself with all possible seriousness why you can't wait
  for C 2015 which will finally introduce a garbage collector,
  instead of manually fooling around with memory pointers today!
  Until then malloc(3) and its MALLOC_OPTIONS may help you a bit,
  too.
- And always revisit your code some time after you have forgotten
  what it is for;  may you never have the material pressure to
  release it at an earlier time.

 Chris Smith

May the juice be with you.

--steffen