Menu
▾
▴
#371 code analysis, flaw detection, debugging
Would you like to use these tools?
- http://en.wikipedia.org/wiki/Static_code_analysis
- http://en.wikipedia.org/wiki/Memory_debugger
Logged In: YES
user_id=249980
Sure would! I gave valgrind a while ago, but didn't come up with anything
positive. I fell prey to some false positives from another static analysis
tool recently and had to back some of them out. Do you have some
favorites or experiences to share?
Logged In: YES
user_id=572001
I want secure software. So I suggest to use some safety
checks.
Did you try "http://splint.org/"?
Logged In: YES
user_id=875547
Originator: NO
I regularly use MALLOC_OPTIONS=A and valgrind
and usually compile Privoxy with stack smashing
protection and similar mechanisms that are supposed
to crash the program if it doesn't play by the rules.
However, like David I'm not the biggest fan of
static analysis tools because the ones I tried
(including splint) produce a lot of noise
and most warnings are completely bogus or
just not important enough to be fixed right now.
Of course you're welcome to use them yourself
and let us know if you run into serious problems,
but note that if you report less serious ones you
should consider sending in a patch as well.
For example we don't need splint to tell us
that we still use "unsafe" string functions
and that switching to safer ones would be a good
idea. On the other hand, if someone would send in
actually patches to do this in a cross-platform way
I can guarantee you that we would include them
immediately.
Of course if someone reported that we use "unsafe"
string functions in a way that is actually
unsafe this would be a real problem and worth
fixing right now.
Logged In: YES
user_id=572001
Originator: YES
It is nice to read about your experiences.
Lint tools should be better to increase safety than malloc debuggers. Would you like to acknowledge that they show any details that can be registered in an issue tracking system?
Can you imagine that the code quality can be improved with their help if such tools would become an essential part of your software build process?
Logged In: YES
user_id=875547
Originator: NO
You can register pretty much anything in an issue
tracking system, but if it's not a real issue,
registering it is probably not that useful.
Hunting down lint warnings can take quite some
time. It may be worth it, if one of the lint
warnings turned out to be actually reasonable
and helped to find a real problem, but otherwise
that time is wasted.
Integrating a linter in a meaningful way into Privoxy's
build process would be a lot of work and currently there
are probably more important things to do.
Also if the integrated linter was good enough to
help finding real problems it should work as good
without being integrated into the build process.
Do you personally have any experience to share
or did you just read about static code analysis
without trying it yourself?
David already asked the same question,
but from your answer it's not clear to me.
Logged In: YES
user_id=572001
Originator: YES
I know that there are efforts involved. I see such tools as a possibility to lower security concers that are connected with proxy servers.
The C language has got many potentials to make programming errors.
I tried to perform safety checks with SPlint on other source files.
Logged In: YES
user_id=875547
Originator: NO
Well it looks like no one who thinks these
efforts would be worth it has the time or
interest to do it.
Maybe you could change our mind by reporting
an actual problem that you found in Privoxy
by using splint or a similar tool?
Logged In: YES
user_id=572001
Originator: YES
Would you like to check how a wrong test would be reported for the function "cgi_error_no_template"?
http://splint.org/manual/html/sec5.html
http://ijbswa.cvs.sourceforge.net/ijbswa/current/cgi.c?revision=1.85&view=markup :
"...
line 1506:
rsp->status = strdup(status);
if (rsp->body == NULL)
..."
This kind of wrong error handling seems to get repeated at line 1583.
Is the instruction "if (rsp->status == NULL)" more appropriate there?
Logged In: YES
user_id=875547
Originator: NO
You're right, the error handling code
was wrong. Thanks for the report, I fixed it.
However I'm unsure how splint helped you
to find this problem?
If I run splint against cgi.c before and after
the commit I get the same amount of warnings,
and none of them is about this one.
Logged In: YES
user_id=572001
Originator: YES
Thanks for this little correction.
I admit that I spot this and the other open issue myself, too.
https://sourceforge.net/tracker/?func=detail&atid=111118&aid=1630918&group_id=11118
But if the tool would be updated to support current compilation standards (C99 ...) and Pthreads, it would become more helpful to detect faulty code.
http://splint.org/manual/html/sec8.html
http://businessweek.com/technology/content/oct2006/tc20061006_394140.htm